[48] in WWW Security List Archive

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

Re: GSS API (as a DLL)...

daemon@ATHENA.MIT.EDU (Martin Bokaemper)
Wed Aug 17 18:32:26 1994

Date: Wed, 17 Aug 94 16:36 GMT+0100
From: mnbokaem@pizza.franken.de (Martin Bokaemper)
To: www-security@ns1.rutgers.edu

>[crow!rik@uunet.uu.net writes]
>Like Bernhardt of Physik.TU-Muenchen.DE mentioned, I am very concerned
>about the security of DLL, or shared library-like tools.  These have been
>a big problem, especially on Sun systems, where an attack might take the
>form of placing a doctored shared library ahead of the appropriate shared
>library.  It would hardly do to create an security mechanism with inherent
>security problems.

The implementation of the part of the API concerning loading and invoking 

of cryptoroutines is highly system specific, even between different flavours
of unix. So it should be no problem to have a 'static' implementation of 

that API:
For systems that do not have an appropriate mechanism for dynamic loading
all the necessary routines are linked statically and every new cryptolibrary
requires relinking - this is cumbersome but will make this API usable on
_all_ platforms.

I think this generic API is very import not only because of the flexibility 

in choosing protocols but it also makes international use of software much
easier since patent and export issues no longer matter while writing client
or serversoftware:
The programms could easily be exchanged while cryptolibraries cannot - export
from the US is not the only problem: imported cryptosystems probably use 

algorithms under patent protection in the US so their use would be a patent
infringement. But it is much easier to build (national-law-)specific 

libraries as to build complete applications, especially because most of 

the necessary parts for such a library are widely available (e.g. SecuDE).

Martin Bokaemper.
--

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