From: Marc W. Mengel <mengel@dcdmwm.fnal.gov>
Date: Fri, 4 Feb 94 15:29:56 PST
To: "Alan (Miburi-san) Wexelblat" <wex@media.mit.edu>
Subject: Re: CERT advisory
In-Reply-To: <9402041825.AA27913@media.mit.edu>
Message-ID: <9402042327.AA43567@dcdmwm.fnal.gov>
MIME-Version: 1.0
Content-Type: text/plain



In <9402041825.AA27913@media.mit.edu>  you write:
  [Some items of interest to C-punks include CERT's advocacy of stopping
  cleartext transmission of password (no shit sherlock), and their proposed
  solutions, including the use of one-time passwords which I had queried about
  on this list a few months back.  Of course they don't mention any sort of
  real encryption, let alone PGP.  How hard would it be to build in PGP
  security to the transmission layer of something like FTP?  Seems like a
  fairly simple problem, given that any site which supports anonymous FTP can
  publish a public key.  Even if we assume that encryption would slow down the
  file transmission too much, we could still use it for the
  login/authentication part of the session...  --AW]

Since the command channel is flat ascii, one could extend the protocol
with a pgp-password command, which would send the password encrypted in the
server's public key.  Similarly one could use the sort of convention that
the wu-ftpd does to request encrypted files... simply request file.pgp,
just like you request file.z, file.gz, etc.

Of course, there really *ought* to be an RFC for it, but I'm thinking
something like a command

 	666 PGPL
	-----BEGIN PGP MESSAGE-----
	...
	-----END PGP MESSAGE-----

which would send an encrypted login and password.

The other piece to hack up would be the ftp client, it would have to
ask for your login/password on the ftp server host, then crank that
through pgp, and send an ELOGIN command down the socket -- no problem.

The big issue, in my mind, is how the ftpd is going to get the key
to unlock the *system's* private key... Do you compile it into the
code?  Should ftpd ask for it when it comes up? 

Marc