NAME

       O-SAFT / fetchfile

DESCRIPTION

   Introduction
       With  the  server  protocol  extension  O-SAFT (Offer Simple Asynchronous File Transfer) and the matching
       client fetchfile there is an easy method of retrieving files from a SAFT server. This is a direct analogy
       to the SMTP and POP or APOP protocol suite in the world of e-mail transfer.

       Overview:

               - How does O-SAFT/fetchfile work?
               - What to do on the client side?
               - What to do on the server side?
               - How about security issues?

   How does O-SAFT/fetchfile work?
       O-SAFT  is  an  extension to the existing SAFT protocol and allows athenticated clients to retrieve files
       from a (remote) server. The implemention is the server sendfiled and the client fetchfile.

       O-SAFT uses a dedicated pgp key pair to authenticate the fetchfile session.  The private key will be kept
       on  the  client  side, the public key must tbe present at the server side. For security reasons this will
       NOT be your regular e-mail pgp key pair, but a separate pair of pgp keys, uniquely assigned for fetchfile
       transfers.  You  will have to create a pair of pgp keys for this purpose befor using the fetchfile client
       for the first time (see below).

       Fetchfile can provide a directory listing of available files from the server, retrieve  files  or  delete
       files.  After  retrieving  a  file,  it will be placed in the regular spool directory, not in the current
       directory! You will have to use the receive command to transfer the files from  the  spool  directory  to
       your current directory afterwards.

       If there already exists a regular sendfile spool directory /var/spool/sendfile on the client side it will
       be used, otherwise a $HOME/.sfspool will be  created.  Fetchfile  will  be  running  without  using  root
       permissions on the client side.

   What to do on the client side?
       You  must  have  pgp-2.6.x  installed  and  the binaries must be available through your $PATH environment
       variable.

       First, and ONLY ONCE before using fetchfile the very first time, you have to create a fetchfile  pgp  key
       pair (only pgp-2.6.x is supported!):

       fetchfile -I

       Please  only  hit  'ENTER'  when being asked for a pass phrase! This will create a special non-passphrase
       protected key pair for O-SAFT.

       After  this  initialization  you  will  have  a  file  /var/spool/sendfile/$USER/config/public.pgp  resp.
       $HOME/.sfspool/public.pgp

       Please  send this file to root@SAFT-server, who has to save this public key file into the appropiate user
       configuration directory.

       Example:

       sendfile -c 'my O-SAFT puplic key' /var/spool/sendfile/$USER/config/public.pgp root@bofh.belwue.de

       (This prelimary action will enable you to use the SAFT server and will prevent othes  from  abusing  your
       name or SAFT-account on the server.)

       After preparing the pgp keys an both sides, you can invoke fetchfile on a regular basis:

       fetchfile -l
               list files on the server

       fetchfile -a
               retrieve all files from server

       fetchfile -daf *aol.com
               delete all files from the AOL domain

       There is a detailed description of all capabilities in the fetchfile(1) man page.

       For configuring the server SAFT account by the client user there are two options:
            fetchfile -Cw=config
            fetchfile -Cw=restrictions

       Using  this  the two local configuration files will be transfered from the local current directory to the
       SAFT server. The details of the configuration can be found in the sendfile(1) man page.

       With using
            fetchfile -Cr=config
            fetchfile -Cr=restrictions

       the files will be retrieved back and will be displayed to STDOUT.

   What to do on the server side?
       pgp-2.6.x must be installed. The system adminsitrator  needs  to  run  sfdconf  -e  config  add  set  the
       following option:

       fetchfile = on

       The  system  administrator  must  create a user account (if it does not yet exist). This account does not
       need an interactive login shell and does not need a valid password; the login shell could be  /bin/false.
       The  only  purpose is to enable the sendfiled to check out the user and to create a local spool directory
       (this method is well known for creating POP mail accounts).

       The client user will create the initial pgp key pair and the public key (public.pgp) will be sent to  the
       system  administrator  of  the  server.   This  key  has  to  be placed into the config directory for the
       particular user.  Assuming the user name is  bozo,  the  system  administrator  will  have  to  type  the
       following (under root permissions):

            receive -f bozo@* -b bozo public.pgp
            su bozo
            cd /var/spool/sendfile/bozo/config
            receive public.pgp

       (the first receive resends the file public.pgp from the sender bozo@* to the
        local user bozo)

   How about security issues?
       O-SAFT  uses  a  tcp  challenge/response authentication with a pgp signature.  This opens the possibility
       that the session can be attacked through tcp hijacking. We are well aware of this, but tcp  hijacking  is
       not  easy  and  only possible if the attacker has direct access to the transport media (e.g. listening on
       the same ethernet cable/segment) and has access to a set of  pretty  nice  cracker  tools.  With  regular
       operating system supplied software it is not possible to attack a session.

SEE ALSO

       sendfile(1), fetchfile(1), sendfiled(8).

AUTHOR

       Ulli Horlacher  -  framstag@rus.uni-stuttgart.de

       translated by andreas@citecs.de