Subject: Re: rfc2228 in ftpd
To: Perry E. Metzger <perry@piermont.com>
From: Aidan Cully <aidan@kublai.com>
List: tech-security
Date: 06/24/2002 00:43:42
On Sun, Jun 23, 2002 at 11:27:21PM -0400, Perry E. Metzger wrote:
> I'm well aware of that. I'm more interested in the question of whether
> or not Yet Another Security Mechanism is a good idea.

Let me try and list some advantages and disadvantages of the various
alternatives...
SSL pro:
 * Works with any user, anonymous, whatever.
con:
 * No authentication support.  The server will need a plaintext copy of
   your password to authenticate you.
 * Annoying to get a certificate.  You can self-sign your cert, but then
   you need to change your applications to think of you as a CA.  Who
   knows what mechanisms various apps on whatever platforms use to modify
   their internal lists of acceptable certificate authorities?  And you
   have to do this for everyone in your organization.
2228 pro:
 * Authentication.
con:
 * you usually need a pre-existing authentication context to use this.
 * the proposed patch doesn't support SSL out of the box.

Kerberos is the best readily available authentication model for use
within organizations.  You can use scp for copying files instead of
FTP, but first of all it's a pain to synchronize your public keys on
all the servers you want to talk to (not just adding to the
authorized_keys files, but deleting when you don't want to use a key
anymore.  if you don't use public/private authentication, then you'll
need to type your password a lot.), and secondly it assumes a login
account on the host (even if our ftpd appears to want a login account,
it's still possible to run it inside of a chroot() so that users can
only use the FTP service).

As far as I'm concerned, the reasons we want this support (if not
this patch) are, in this order:
1. authentication.
2. pain to get an SSL certificate.
3. pain to maintain authorized_keys files.
4. pain to retype your password all the time.

--aidan