Subject: Ftp-WG: FTP over SSL

From: "Paul V Ford-Hutchinson" <[email-masked]>
Date: Tue, 7 Aug 2001 05:52:30 -0500

The ftp/ssl draft has been around now since 1997 and I feel it is time to 
ask for it to be put onto Standards Track.

(see http://www.ietf.org/internet-drafts/draft-murray-auth-ftp-ssl-07.txt)

Do people on these lists have strong views on this ?  I am struggling to 
find a path through the IETF processes for putting individual submissions 
onto Standards Track, so I'd love to know what others did.

For a page of links to implementations, see 
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html .

Cheers,
Paul

--
Paul Ford-Hutchinson :  eCommerce application security : 
[email-masked]
MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 
462005

---

From: "Mark Symons" <[email-masked]>
Date: Thu, 23 Aug 2001 21:51:24 -0500

With apologies for not replying sooner...

> The ftp/ssl draft has been around now since 1997 and I feel
> it is time to ask for it to be put onto Standards Track.
 
> Do people on these lists have strong views on this ?

I would love to see the draft move to Standards Track.  That's because WS_FTP client and server both use this draft.

When I go back to ftp-ssl-05, there was brief mention of the HOST command.  This mention was removed from ftp-ssl-06, because HOST had been dropped from the MLST draft.  I am not holding my breath waiting for HOST to be re-introduced into its own draft,  although I think it's critical for implementing ftp/ssl on virtual hosts.  How else can one have a separate certificate store for each virtual host?

My worry about the ftp/ssl draft is that section 15.1.1 is rather vague on this issue.  In referring to such future extensions it says "interaction...will need to be carefully considered".  I would feel much more comfortable if this were expanded to show that the definition of ftp/ssl is robust enough to allow for a future extension such as HOST.

Mark Symons
Ipswitch, Inc
Augusta GA

---

From: "Gregory A Lundberg" <[email-masked]>
Date: Fri, 24 Aug 2001 08:18:55 -0500

> I am not holding my breath waiting for HOST to be re-introduced into its
own draft

Not holding your breath is a Very Good idea.

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.)

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.

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).