[48] in WWW Security List Archive
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.
--