[13] in WWW Security List Archive

home help back first fref pref prev next nref lref last post

Re: Kerberos authentication for X-Mosaic 2.4 and NCSA HTTPD

daemon@ATHENA.MIT.EDU (hallam@dxal18.cern.ch)
Sun Aug 14 15:01:56 1994

From: hallam@dxal18.cern.ch
To: John Ludeman <johnl@microsoft.com>, www-security@ns1.rutgers.edu
Cc: hallam@dxal18.cern.ch
In-Reply-To: Your message of "Fri, 12 Aug 94 12:32:31 +0700."
             <9408121950.AA03302@netmail2.microsoft.com> 
Date: Sun, 14 Aug 94 18:06:54 +0200

>I would strongly suggest taking this so far as to allow multiple 
>pluggable security providers using Dynamic Link Libraries.  Virtually 
>every platform of interest supports some form of DLLs.  This would 
>allow a corporation to customize for their particular authentication 
>scheme or allow RSA to provide a commercial encryption algorithm 
>without having to munge the sources and compile  (which I suspect is 
>beyond the capabilities of many potential customers) or better yet, if 
>the security provider standard is done right and is well written, plug 
>into any commercial Web viewer.  This also allows wide adoption of 
>trade secret sensitive algorithms without having to give out the source code.

I think the use of sharable images, dynamic link libraries or whatever is 
certainly one approach that should be supported.

We are also interested in true dynamic linking. It is technically feasible to
have a system where if a browser does not know how to handle a content type
it could go off to a server to grab the code to handle it and link it on
the fly. Of course there may be "a few" security implications.

The common ground is that we have to have well defined data structures and
code interfaces. At the moment I am using the VMS calling standard as a model
for how to build the interfaces. Although this is a bit dated, being based on
C and FORTRAN rather than C++ it does permit multi language programming.

Basicaly the rules are:-

1) Every routine is a function returning an integer status code

2) It is the responsibility of the library to allocate all memory required for
	returned data structures.

3) No global or static variables except where required for initialisation or
	for locking structures..

4) Every routine to be fully reentrant.


Personally I find this a bit restrictive and have been playing round with
usiong thin layer shells. These enable the FORTRAN interface to the library
to have a FORTRAN feel, the C++ to have a C++ feel etc. Its not that hard
to write a synthesizer to generate such shells from C source.

For the time being it is C by the way. C++ is not avaliable on a number
of significant platforms, and on some that it is avaliable for the compilers
are not stable enough. 


	Phill H-B

home help back first fref pref prev next nref lref last post