Ian --
The database software uses a library called DBLIB to talk to the database over the
network.
The underlying protocol is called TDS and was originally developed by SYBASE. There
are
three implementations of the client side of this which work on various platforms:
1. SYBASE Open/Client (proprietary OpenVMS, various unix)
2. FREETDS - open source - reverse engineered - www.freetds.org
3. MS Sqlserver (proprietary Win32 only)
Our software works with any of these three. The only one of these we could hack on
would be freetds. If this can be avoided it would be much better!
Recently we found out that SQLServer has a switch which tells it to use SSL when
talking over the network. Using microsoft's client (assuming the appropriate
certificates are in place) it just works. Some crude attempts at wrapping sybase's
library using sslwrap or stunnel did not. If we could get this to work, it could be
the complete solution. These wrapper programs seem to be set up to wrap servers
rather than clients. If they could be made to wrap the client, and turning on SSL
in the database communication library does not cause any non-standard conversations,
we are all set. If we have to we can address the second of these issues
(potentially non-standard conversations) by wrapping the server instead of turning
on the built in encryption.
Another tack we can take is that if we implement the database access as part of
MDSplus's expression evaluator, and we have globus servers under WIN32, then we are
all set. The clients authenticate themselves locally, and connect to a secure
MDSplus server on the WINtel box with the database on it. The users database
password is retrieved from the X.509 directory, then passed securely over the wire,
finally it is presented to the database by the mdsplus server running locally with
the database. This solution is probably the one we want to end up with. We
currently have a project to do the MDSplus part of this, but when it is done it will
still need the window globus implementation.
One thing which would be really great to have, but we have been unable to find is a
windows routine which allows a server to impersonate a user without knowing their
password. This probably does not exist, but if it did, after the user connected and
their credential was verified, the server could just fork a process for them which
would do 'trusted' database operations (no password required).
-- josh
Ian Foster wrote:
> What is the protocol that the client uses to communicate with the MS-SQL
> server once it has the password? Is it ODBC? Do we have the source code
> for this client code? Sorry, I think these questions have been asked
> before, but I can't recall the answers.
>
> Ian.
>
> At 04:15 PM 10/16/2001 -0700, Mary Thompson wrote:
> >As I recall the SSL wrapper scheme, there was going to be an GSI/ssl
> >enabled server on the MSSQL machine which would use the client's Grid
> >credential to generate a one-time MSSQL password. It would then hand
> >that password to the MSSQL server and back to the client. Then the
> >client could use that password and proceed as usual.
> >
> >If the SSL server runs on a different platform, then the only security
> >problem is how to hand the password off to the MSSQL machine securely.
> >There may be several solutions here
> > 1) just hand it off unsecurely and argue that it is small window of
> >vulnerablilty and it will go away once the server runs on the Windows
> >machine
> > 2) write the SSL server just using generic openSSL code which does run
> >on Windows, though we may need a competent Windows programmer to get it
> >to build.
> >Actually writing such a server in Java might work, since it could be
> >written and debugged on Unix and then just dropped onto Windows. Java
> >supports SSL connections pretty transparently. You just need to load the
> >right socket factory.
> >
> >If this looks like the right way to go, I can check into writing a Java
> >SSL server. How would it hand the password to the MSSQL server?
> >
> >Mary
> >--
> >---------------------------------------------------------------------
> >Mary R. Thompson <MRThompson@lbl.gov>
> >Distributed Security Research Group (510) 486-7408
> >Lawrence Berkeley National Lab http://www-itg.lbl.gov/~mrt
> >----------------------------------------------------------------------
> >
> >===============================================================================
> >
> >This message was sent to the SciDAC National Fusion Collaboratory (NFC)
> >workers list nfc-workers. Visit the Collaboratory at
> ><http://www.fusiongrid.org/>.
> >
> >To unsubscribe from this list, please send a message to
> >majordomo@fusion.gat.com with the following text in the *body* of the
> >message: unsubscribe nfc-workers
> >
> >David P. Schissel: <schissel@fusion.gat.com>
> ><http://fusion.gat.com/~schissel/>
>
> _______________________________________________________________
> Ian
> Foster http://www.mcs.anl.gov/~foster
>
> Math & Computer Science Div. Dept of Computer Science
> Argonne National Laboratory The University of Chicago
> Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A.
> 630 252 4619 (fax 5986) 773 702 3487 (fax 8487)
===============================================================================
This message was sent to the SciDAC National Fusion Collaboratory (NFC)
workers list nfc-workers. Visit the Collaboratory at
<http://www.fusiongrid.org/>.
To unsubscribe from this list, please send a message to
majordomo@fusion.gat.com with the following text in the *body* of the
message: unsubscribe nfc-workers
David P. Schissel: <schissel@fusion.gat.com> <http://fusion.gat.com/~schissel/>
This archive was generated by hypermail 2.1.1 : Thu Feb 07 2002 - 15:40:41 PST