CGI/1.0: last call

ts (
Tue, 7 Dec 93 08:21:38 +0100

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 :

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