[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Integrating ftpd and pam_opie; not getting challenge?



On Wed, 10 Jun 1998, Andrew Morgan wrote:
> Jim's statements about protocols seem to be the main blocking feature
> here.  I can't help feeling that "extending" the protocol would be the
> right way to go... It seems as if this is needed even without needing
> to support PAM.  So much to do, so little time...

	Firstly, as far as "extending" ftp -- given the history of ftp,
what REALLY needs to be done is for someone to start from scratch, remove
the cruft that's been there for 25 years and obsolete for 15, and add the
functionality that people want today (i.e., some form of on-the-fly
compression that can be negotiated between client and server,
pluggable/negotiable encryption, improved authentication system).  I
suspect no-one on this list has a spare lance for that windmill, though. 
As for working around the present protocol, however:

	I've now modified troll-ftpd from
http://www.troll.no/freebies/ftpd.html to be PAMified and to work with
traditional (pam_pwdb) and challenge/response (pam_opie) modules.  In this
message I'll briefly describe how it works and what the limitations are,
just in case anyone is interested or wants to know for future reference.

	The standard FTP authentication is a USER XXX command from the
client, followed by a 331 message from the server, like "331 Password
required for XXX" or "331 Anonymous login okay, enter email address as
password", followed by a PASS ZZZ command from the client.

	In order to wedge a PAM challenge/response module into FTP, the
FTP server must

1) upon receipt of a USER XXX command, pam_start and pam_authenticate
2) the pam_authenticate will callback to the PAM conversation function
3) In OPIE, the PAM conversation function is called with
   PAM_TEXT_INFO -- the challenge.
4) The PAM conversation function is called with PAM_PROMPT_ECHO_OFF --
   looking for the response (OPIE) or the password (pam_pwdb).
5) Here's the key.  If PAM_TEXT_INFO was recorded as in 3), the ftp
   server must issue some variant of "331 Challenge [the PAM_TEXT_INFO]."
   If no PAM_TEXT_INFO came, we assume a "normal" (i.e., like pam_pwdb)
   module and the server must issue "331 Password required for XXX."
   Assuming a text FTP client or a GUI that allows the user to view the 
   FTP control channel, the user can view the challenge, generate the 
   one time password, and type it in to their password prompt.  CuteFTP
   is a known Win32 gui that works this way.
6) The PAM conversation function must read the client commands until it
   sees PASS ZZZ, and then extract the password/passphrase from that line.
   Note, in my hack, any intervening non-PASS commands are ignored.  This 
   isn't too RFC kosher, but it seems to work with my clients.
7) The pass ZZZ is passed back to PAM, control returns to
   pam_authenticate and from there back to normal control flow.
   

Caveats:
1) Not guaranteed to work with modules other than pam_pwdb and pam_opie
2) Requires the ability of the PAM conversation function to take over 
   input/output for the length of the authentication process.
3) I removed "anonymous ftp" capabilities in the process.  They could be 
   added back, but I don't need them for what I'm doing ;>
4) Ignores commands after "USER" and before "PASS."

Credits:
Couldn't have done it without troll-ftpd by Arnt Gulbrandsen
 <agulbra@troll.no> 
Learned how conversation modules work by looking at the PAM patch for
 troll-ftpd by Kelley Lingerfelt <redhat@cococo.net> and
 Michael K. Johnson <johnsonm@redhat.com> 

	I'd be happy to discuss further or share code if anyone is
interested.  

-- 
	gowen -- Greg Owen -- gowen@xis.xerox.com




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []