From petravic@fnal.gov Mon Oct 22 11:38:40 2001
Subject: Anonymous ftp dcache access


Don Petravick's desiderata for "anonymous" access to files in the
Fermilab central systems dcache:


1. Portal Access:  Not supported.

    Does not play well with automated transfers or future grid
    development.

    Work is not difficult to do (assuming portal code is available),
    but is not salient to the department mission.

    User can access other sites and acquire required credentials so no
    one should be stopped by not have this.  For trivial transfers, an
    experimenter with no kerberos infrastructure can access some
    portal node and move the data twice.

    The work has unknown consequences for the software architecture.
    Is there a Java API?  Or are we going to have to use javah?  The
    department would rather put effort in to HRM + Grid FTP.




2. Strong Authentication: Reads and Writes Supported

      a. User with kerberos credentials presents their kerberos
         principle to the kerberos dcache ftp door.
 
      b. Principle is verified with FNAL kdc.  If bad, door exits.
 
      c. The ftp server acquires the client's user name.  There are
         three possibilities by which this happens.  All three
         possibilities end with the server knowing the username. The
         actual method depends on the implementation.
	   i.   User explicitly sends ftp command "user ". 
           ii.  User is prompted for their username and enters it.
           iii. FTP client sends default username without the user
	        explicitly knowing about it.

       Here is an example from Don Petravick that demonstrates that he
       is prompted for his user name on node hppc:

	  hppc> type ftp
	  ftp is hashed (/fnal/ups/prd/kerberos/v1_3a/IRIX-6-5/./bin/ftp)
	  hppc> ftp
	  ftp> debug 1
	  Debugging on (debug=1).
	  ftp> open hppc.fnal.gov
	  Connected to hppc.fnal.gov.
	  220 hppc FTP server (Version 5.60) ready.
	  ---> AUTH GSSAPI
	  334 Using authentication type GSSAPI; ADAT must follow
	  GSSAPI accepted as authentication type
	  Trying to authenticate to 
	    calling gss_init_sec_context
	    ---> ADAT
	    YIIB3QYJKoZIhvcSAQICAQBuggHMMIIByKADAgEFoQMCAQ6iBwMFACAAAACjggEQYYIBDDCCAQigAwIBBaEKGwhGTkFMLkdPVqIfMB2gAwIBA6EWMBQbA2Z0cBsNaHBwYy5mbmFsLmdvdqOB0zCB0KADAgEBoQMCAQKigcMEgc
	    BVmBByPWoUPtZ9LpoAY7CsR7jNdb8cZy/hqk4yJa+sR4lxOaWIc/b+ndPhKu2Ebf7VorWeirKcOEztV/MKo+LWYWYJin5gLsQXbAKxjWZLMojWFmn6eXAuVXSavgzdH4gMMs9X+gxtFHO6PSAZMZzQudUntfpndjcMGMrOwCAL
	    OnB2IUqHKWS2aJEgEPAeUgtXcSjhGt81rUeEKLr9asiragZwpqDxmeQCEfvixrfx58xFmR0eOPgtTDNPCxGCLkKkgZ4wgZugAwIBAaKBkwSBkEcnu8c2hODGMY8h42ic6S5iCq5KL6d7V8CHaZqe/nYjZ0xT4/kCP6HEQLMoiH
	    Nd8vPXSaUvasGR87HIizl9lGfkTJ7OzwZD7G8pP8Rtq9Mgvdfva0UauyRbY2SKBgN6x8AAke35UzT+ACEotcWIpBEBZzGUg2vzKBWQZpuL739E2676RhZMTcHxqtm1UfnFHQ==
	    calling gss_init_sec_context
	    GSSAPI authentication succeeded
	    Name (hppc.fnal.gov:petravic): 
	    ---> USER petravic
	    sealed (MIC) 61 bytes
	    secure_command(USER petravic)
	    encoding 84 bytes MIC
	    YDsGCSqGSIb3EgECAgIBAAD/////kUoURJnrGDP0FchcWYsE+vij+vXRGPaSVVNFUiBwZXRyYXZpYwACAg==
	    232 GSSAPI user petravic@FNAL.GOV is authorized as petravic
	    ---> PWD
	    sealed (MIC) 53 bytes
	    secure_command(PWD)
	    encoding 72 bytes MIC
	    YDMGCSqGSIb3EgECAgIBAAD/////StgyRAExopxhZ4+ybfF5QGJwPGMwXgP7UFdEAAQEBAQ=
	    ---> SYST
	    sealed (MIC) 53 bytes
	    secure_command(SYST)
	    encoding 72 bytes MIC
	    YDMGCSqGSIb3EgECAgIBAAD/////T9b3Vw1MrtXRZbE2K/GA1TOAZFFSBK5SU1lTVAADAwM=
	    215 UNIX Type: L8
	    Remote system type is UNIX.
	    Using binary mode to transfer files.


 
      d. Door looks up username in its admin proxy file and determines
         which kerberos principles are allowed to become username.
         This is the same as .k5login files.  It allows service
         accounts. If principle is not allowed to become username,
         door exits.
 
      e. Door gets username's uid/gid from its admin proxy file and
         checks the file's (or directory's for writes) user and group
         permissions to see if the user is allowed to transfer the
         file. If not, door exits.
 
      f. Door transfers file to/from authenticated user.


3. Weak Authentication Write: Not supported.

      Weak authentication means the user supplied a username to the
      non-kerberized ftp door.  A password is also supplied, but it is
      not checked.  This really means completely open access.

      I think I went a bit overboard. We should check the password, it
      is just that neither username with no password or username with
      password are weak methods.

      Arguments for supplying a clear text password are:
        1) Users expect it.
	2) We are better able to administer the system using the
	   analogous administrative acts for /etc/password files --
	   i.e. disable accounts by putting a special marker in the
	   password file.
	3) For the (inevitable) cases where the username/password
  	   pair get sniffed, we can deal with the user in the way they
  	   expect - give them a "new password". That is much better
  	   than "giving them a new user name", which is the
  	   alternative.  

     Do not want to handle potential embarrassing problem where user 
     stores files with inappropriate names.

     Support of weakly authenticated writes is fraught with problems.
     The criteria is that even the namespace names of the files cannot
     be seen via weak access. A naive implementation would not let a
     person writing a file see the file through the namespace.
     Consequently, people putting files in casually will be surprised
     to not seem then in a "dir". People doing serious production
     would likely be kerberized.

4. Weak Authentication Reads: Supported when experiment allows it.
 
      See comments about weak authentication in item #3 above.

      a. User is given a foreign uid/gid.  Either one will be assigned
         that as "foreign" or nobody/nobody is used.

      b. Door checks its admin proxy file and determines if user's
         file is in a directory subtree that is authorized by the
         experiment for anonymous read access.  By default, no
         directories are authorized. If the directory is not
         authorized, door exits.

      c. Door checks file to see if experiment has set file's other
         permission bits such that anonymous read access is allowed.
         If not allowed, door exits.

      d. Door transfers to anonymous user.