CGI/1.0: last call (ts)
Date: Tue, 7 Dec 93 08:21:38 +0100
From: (ts)
Message-id: <>
In-reply-to:'s message of Mon, 6 Dec 1993 14:13:51 -0500 (EST) <>
Subject: CGI/1.0: last call

   Date: Mon, 6 Dec 1993 14:13:51 -0500 (EST)
   X-Mailer: ELM [version 2.4 PL21]
   Mime-Version: 1.0
   Content-Type: text/plain; charset=US-ASCII
   Content-Transfer-Encoding: 7bit
   Content-Length: 1363
   X-Lines: 26

   sanders@BSDI.COM writes:> 
   > bobj  <> writes:
   > > Authentication must be the responsibility of the script writer.  While
   > Authentication must be the responsibility of the server.  If you want to
   > easily extend the possible authentication schemes then define a spec for
   > authentication scripts, but they should remain seperate from normal scripts,
   > which should not have to deal with authentication, that would be a HUGE
   > security hole.
   Of course this is right.  In the context of the original message,
   passwords for accessing Oracle were the question but my response to
   that used language that was too general.  To try to put my comment
   in context, assuming that the incoming query has traversed the network,
   gained access to the machine, is granted access to the scripts and is
   attempting to access an Oracle database, the *Oracle authentication*
   is the responsibility of the person writing the Oracle access script.  It
   would seem unreasonable to pass Oracle authentication requirements up
   a layer or two into httpd.  It could be done but then httpd would
   end up with and application/authentication-scheme token for each  
   application requiring authentication. Ne c'est pas?  

   I merely propose that application be done without:
   1.  a user:password token
   2.  an application/authentication-scheme in the www server daemon.


 You have in 

 the description for a "Secure RPC Authentication for TELNET and FTP
Version 1.3" 

 A brief description is : 

> This package provides drop in replacements for telnet and ftp client
> and server programs, which use Secure RPC code to provide encrypted
> authentication across the network, so that plaintext passwords are not
> used.  The clients and servers negotiate the availability of SRA so
> that they work with unmodified versions.  These programs require no
> external keyserver or ticket server, and work equally well for local or
> internet wide connections.
 For non US sites, you have a source for the DES encryption library in :

 Copyright file for this source is :
                        DES SOFTWARE PACKAGE
                            Version 2.2
Copyright (c) 1990,1991,1992,1993 Stig Ostholm.
All Rights Reserved
The author takes no responsibility of actions caused by the use of this
software package and does not guarantee the correctness of the functions.
This software package may be freely distributed for non-commercial purpose
as long as the copyright notice is kept. Any changes made should be
accompanied by a comment indicating who made the change, when it was made
and what was changed.
This software package, or any parts of it, may not be used or in any way
re-distributed for commercial purpose without the authors permission.
The author keeps the right to decide between of what is commercial and
what is non-commercial purpose.
Restrictions due to national laws governing the use, import or export of
cryptographic software is the responsibility of the software user/importer/
exporter to follow.
                                        Stig Ostholm
                                        Chalmers University of Technology
                                        Department of Computer Engineering
                                        S-412 96 Gothenburg
                                        Phone: +46 31 772 1703
                                        Fax:   +46 31 772 3663

Guy Decoux