#!/bin/sh # This is a shell archive (produced by GNU sharutils 4.1). # To extract the files from this archive, save it to some FILE, remove # everything before the `!/bin/sh' line above, then type `sh FILE'. # # Made on 1995-10-17 20:41 PDT by . # # Existing files will *not* be overwritten unless `-c' is specified. # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 950 -rw-rw-r-- README # 2760 -rw-rw-r-- dual-relays.fig.uu # 2924 -rw-rw-r-- dual-relays.figtex # 2285 -rw-rw-r-- rotate.sty # 1409 -rw-rw-r-- secpaper.bib # 56484 -rw-rw-r-- secpaper.tex # touch -am 1231235999 $$.touch >/dev/null 2>&1 if test ! -f 1231235999 && test -f $$.touch; then shar_touch=touch else shar_touch=: echo echo 'WARNING: not restoring timestamps. Consider getting and' echo "installing GNU \`touch', distributed in GNU File Utilities..." echo fi rm -f 1231235999 $$.touch # # ============= README ============== if test -f 'README' && test X"$1" != X"-c"; then echo 'x - skipping README (file already exists)' else echo 'x - extracting README (text)' sed 's/^X//' << 'SHAR_EOF' > 'README' && X X X X X ################################################ X # # X # ## ## ###### ####### ## ## ## ## ## # X # ## ## ## ## ## ### ## ## ## ## # X # ## ## ## ## #### ## ## ## ## # X # ## ## ###### ###### ## ## ## ## ### # X # ## ## ## ## ## #### ## ## ## # X # ## ## ## ## ## ## ### ## ## ## # X # ####### ###### ####### ## ## ## ## ## # X # # X ################################################ X X X X The following paper was originally published in the X Proceedings of the Fourth USENIX UNIX Security Symposium X Santa Clara, California, October 4-6 1993. X X X X X For more information about USENIX Association contact: X X 1. Phone: 510 528-8649 X 2. FAX: 510 548-5738 X 3. Email: office@usenix.org X 4. WWW URL: http://www.usenix.org X X X X SHAR_EOF $shar_touch -am 1017204095 'README' && chmod 0664 'README' || echo 'restore of README failed' shar_count="`wc -c < 'README'`" test 950 -eq "$shar_count" || echo "README: original size 950, current size $shar_count" fi # ============= dual-relays.fig.uu ============== if test -f 'dual-relays.fig.uu' && test X"$1" != X"-c"; then echo 'x - skipping dual-relays.fig.uu (file already exists)' else echo 'x - extracting dual-relays.fig.uu (text)' sed 's/^X//' << 'SHAR_EOF' > 'dual-relays.fig.uu' && begin 664 dual-relays.fig M(T9)1R R+C$*.# @,@HR(#(@," S("TQ(# @," P(# N,# P(#<@," P"@D@ M,C$Y(#,V.2 R,3D@,S$Y(#$S.2 S,3D@,3,Y(#,V.2 R,3D@,S8Y(#DY.3D@ M.3DY.0HR(#(@," S("TQ(# @," P(# N,# P(#<@," P"@D@,C$Y(#(T.2 R M,3D@,30$*-" Q(#(@,3(@," M,2 P(# N,# P,# @," Q,B V-B Q-SD@,S,Y M($1"+4QI8G)A 'dual-relays.figtex' && \setlength{\unitlength}{0.010000in}% % \begingroup\makeatletter % extract first six characters in \fmtname \def\x#1#2#3#4#5#6#7\relax{\def\x{#1#2#3#4#5#6}}% \expandafter\x\fmtname xxxxxx\relax \def\y{splain}% \ifx\x\y % LaTeX or SliTeX? \gdef\SetFigFont#1#2#3{% X \ifnum #1<17\tiny\else \ifnum #1<20\small\else X \ifnum #1<24\normalsize\else \ifnum #1<29\large\else X \ifnum #1<34\Large\else \ifnum #1<41\LARGE\else X \huge\fi\fi\fi\fi\fi\fi X \csname #3\endcsname}% \else \gdef\SetFigFont#1#2#3{\begingroup X \count@#1\relax \ifnum 25<\count@\count@25\fi X \def\x{\endgroup\@setsize\SetFigFont{#2pt}}% X \expandafter\x X \csname \romannumeral\the\count@ pt\expandafter\endcsname X \csname @\romannumeral\the\count@ pt\endcsname X \csname #3\endcsname}% \fi \endgroup \begin{picture}(340,302)(120,410) \thicklines \put(140,470){\framebox(80,50){}} \put(140,590){\framebox(80,70){}} \put(360,590){\framebox(80,70){}} \put(360,470){\framebox(80,50){}} \put(220,625){\vector(-1, 0){ 0}} \put(220,625){\vector( 1, 0){140}} \put(180,590){\vector( 0, 1){ 0}} \put(180,590){\vector( 0,-1){ 70}} \put(400,520){\vector( 0,-1){ 0}} \put(400,520){\vector( 0, 1){ 70}} \thinlines \put(120,410){\framebox(120,260){}} \put(340,410){\framebox(120,260){}} \multiput(290,660)(0.00000,-8.57143){4}{\line( 0,-1){ 4.286}} \put(290,630){\vector( 0,-1){0}} \multiput(255,555)(-8.23529,0.00000){9}{\line(-1, 0){ 4.118}} \put(185,555){\vector(-1, 0){0}} \multiput(325,555)(8.23529,0.00000){9}{\line( 1, 0){ 4.118}} \put(395,555){\vector( 1, 0){0}} \put(180,420){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}client machine}}} \put(400,420){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}server machine}}} \put(180,640){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{bf}relay}}} \put(180,500){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{bf}DB-Library}}} \put(180,482){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{bf}Application}}} \put(400,500){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{bf}Open}}} \put(400,482){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{bf}Server}}} \put(400,640){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{bf}relay}}} \put(180,622){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{bf}(``outbound}}} \put(180,604){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{bf}mediator'')}}} \put(400,622){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{bf}(``inbound}}} \put(400,604){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{bf}mediator'')}}} \put(290,700){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}Encrypted}}} \put(290,664){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}connection}}} \put(290,682){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}network}}} \put(290,565){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}Unencrypted}}} \put(290,547){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}local}}} \put(290,529){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}connections}}} \end{picture} SHAR_EOF $shar_touch -am 1017203995 'dual-relays.figtex' && chmod 0664 'dual-relays.figtex' || echo 'restore of dual-relays.figtex failed' shar_count="`wc -c < 'dual-relays.figtex'`" test 2924 -eq "$shar_count" || echo "dual-relays.figtex: original size 2924, current size $shar_count" fi # ============= rotate.sty ============== if test -f 'rotate.sty' && test X"$1" != X"-c"; then echo 'x - skipping rotate.sty (file already exists)' else echo 'x - extracting rotate.sty (text)' sed 's/^X//' << 'SHAR_EOF' > 'rotate.sty' && % % These macros allow you to rotate or flip a \TeX\ box. Very useful for % sideways tables or upsidedown answers. % % To use, create a box containing the information you want to rotate. % (An hbox or vbox will do.) Now call \@rotr\boxnum to rotate the % material and create a new box with the appropriate (flipped) dimensions. % \@rotr rotates right, \@rotl rotates left, \@rotu turns upside down, and % \@rotf flips. These boxes may contain other rotated boxes. % \newdimen\@rotdimen \newbox\@rotbox X \def\@vspec#1{\special{ps:#1}}% passes #1 verbatim to the output \def\@rotstart#1{\@vspec{gsave currentpoint currentpoint translate X #1 neg exch neg exch translate}}% #1 can be any origin-fixing transformation \def\@rotfinish{\@vspec{currentpoint grestore moveto}}% gets back in synch % % First, the rotation right. The reference point of the rotated box % is the lower right corner of the original box. % \def\@rotr#1{\@rotdimen=\ht#1\advance\@rotdimen by\dp#1% X \hbox to\@rotdimen{\hskip\ht#1\vbox to\wd#1{\@rotstart{90 rotate}% X \box#1\vss}\hss}\@rotfinish} % % Next, the rotation left. The reference point of the rotated box % is the upper left corner of the original box. % \def\@rotl#1{\@rotdimen=\ht#1\advance\@rotdimen by\dp#1% X \hbox to\@rotdimen{\vbox to\wd#1{\vskip\wd#1\@rotstart{270 rotate}% X \box#1\vss}\hss}\@rotfinish}% % % Upside down is simple. The reference point of the rotated box % is the upper right corner of the original box. (The box's height % should be the current font's xheight, \fontdimen5\font, % if you want that xheight to be at the baseline after rotation.) % \def\@rotu#1{\@rotdimen=\ht#1\advance\@rotdimen by\dp#1% X \hbox to\wd#1{\hskip\wd#1\vbox to\@rotdimen{\vskip\@rotdimen X \@rotstart{-1 dup scale}\box#1\vss}\hss}\@rotfinish}% % % And flipped end for end is pretty ysae too. We retain the baseline. % \def\@rotf#1{\hbox to\wd#1{\hskip\wd#1\@rotstart{-1 1 scale}% X \box#1\hss}\@rotfinish}% % % Now the user interface for LaTeX: \rotate[type]{text} where % ``type'' is `l' for left, `r' for right, `u' for upside-down, or % `f' for flip. `l' is the default. % \def\rotate{\@ifnextchar[{\@rotate}{\@rotate[l]}} \def\@rotate[#1]#2{\setbox\@rotbox=\hbox{#2}\@nameuse{@rot#1}\@rotbox} X SHAR_EOF $shar_touch -am 1017203995 'rotate.sty' && chmod 0664 'rotate.sty' || echo 'restore of rotate.sty failed' shar_count="`wc -c < 'rotate.sty'`" test 2285 -eq "$shar_count" || echo "rotate.sty: original size 2285, current size $shar_count" fi # ============= secpaper.bib ============== if test -f 'secpaper.bib' && test X"$1" != X"-c"; then echo 'x - skipping secpaper.bib (file already exists)' else echo 'x - extracting secpaper.bib (text)' sed 's/^X//' << 'SHAR_EOF' > 'secpaper.bib' && @inproceedings{Kerberos, X AUTHOR = "Jennifer G. Steiner and Clifford Neuman and Jeffrey I. Schiller", X TITLE = "{Kerberos: An Authenticaion Service for Open Network Systems}", X BOOKTITLE = "Usenix Conference Proceedings", X YEAR = 1988, X PAGES = "191-202", X ADDRESS = "Dallas, Texas", X MONTH = "February" } X @inproceedings{SPX, X AUTHOR = "J. Tardo and K. Alagappan", X TITLE = "{SPX: Global authentication using public key certificates}", X BOOKTITLE = "Proceedings of the IEEE Computer Society Symposium on Research in Security and Privacy", X YEAR = 1991, X PAGES = "232-244", X ADDRESS = "Oakland, California", X MONTH = "May" } X @inproceedings{Treese, X AUTHOR = "G. Winfield Treese and Alec Wolman", X TITLE = "{X Through the Firewall, and Other Application Relays}", X BOOKTITLE = "Usenix Conference Proceedings", X YEAR = 1993, X PAGES = "87-99", X ADDRESS = "Cincinnati, Ohio", X MONTH = "June" } X @techreport{XDR, X AUTHOR = "{Sun Microsystems, Inc.}", X TITLE = "{XDR: External Data Representation Standard}", X INSTITUTION = "Network Working Group of the Internet Engineering Task Force", X YEAR = "1987", X MONTH = "June", X TYPE = "RFC", X NUMBER = "1014", } X @book{DCE, X AUTHOR = "{Open Software Foundation}", X TITLE = "Application Development Reference", X PUBLISHER = "Open Software Foundation", X YEAR = "1992", X SERIES = "OSF DCE 1.0 documentation set", X EDITION = "Update 1.0.1", X MONTH = "July", X VOLUME = "1" } SHAR_EOF $shar_touch -am 1017203995 'secpaper.bib' && chmod 0664 'secpaper.bib' || echo 'restore of secpaper.bib failed' shar_count="`wc -c < 'secpaper.bib'`" test 1409 -eq "$shar_count" || echo "secpaper.bib: original size 1409, current size $shar_count" fi # ============= secpaper.tex ============== if test -f 'secpaper.tex' && test X"$1" != X"-c"; then echo 'x - skipping secpaper.tex (file already exists)' else echo 'x - extracting secpaper.tex (text)' sed 's/^X//' << 'SHAR_EOF' > 'secpaper.tex' && \documentstyle[doublespace,simplemargins,times,epsf,rotate]{article} % Change this if you decide not to use Times-Roman or to change the % font size of the document. \newfont{\boldit}{ptmbi scaled 1500} X \setleftmargin{1.25in} \setrightmargin{1.25in} \settopmargin{1in} \setbottommargin{1in} \setstretch{1.2} \pagestyle{empty} \date{} X \author{{\it Jonathan I. Kamens}\\ {\it OpenVision Technologies, Inc.}\\ {\bf jik@security.ov.com}} \title{Retrofitting network security to third-party applications ---\\ the SecureBase experience} X \newlength{\myboxwidth} \setlength{\myboxwidth}{2in} \newcommand{\mybox}[1]{\multicolumn{1}{|l|}{\parbox[c]{\myboxwidth}{\raggedright\vspace*{2pt} #1 \vspace*{2pt}}}} \newcommand{\goto}[1]{{\bf $\rightarrow$ #1}} X \begin{document} X \maketitle X \thispagestyle{empty} X \begin{abstract} \noindent Systems such as Kerberos, designed to provide secure user and service authentication over insecure open networks, continue to gain acceptance in the UNIX world. There are both freely available and commercial products which reduce the vulnerabilities inherent in trusting ``traditional'' UNIX security in a distributed environment. However, such products generally do not provide similar protection for third-party applications which have their own network security paradigms. This paper shows how such protection can be extended to encompass SYBASE, a widely-used, distributed database system. The experience with SYBASE is generalized to other network applications. \end{abstract} X \section{Introduction} X As distributed computing has become more prevalent, computer security technology has evolved to meet the demand for robust security against network-based attacks. However, many third-party applications have failed to keep up with this evolution and show no signs of preparing to catch up in the near future; these applications are therefore often unacceptably vulnerable to network attacks. X Since it is often impossible for the end-user site to make source-code-level changes to third-party applications, and since waiting for vendors to fix major security problems can often lead to a very long wait indeed, some other method must be found for improving security. Although not every third-party application can be successfully secured, and no universal solution exists for securing all applications, some classes of applications are particularly well-suited to external security enhancements. Relational database technology is one such class. X In this paper, we describe the approach we used to develop SecureBase, a product which enhances the security of a specific relational database system, SYBASE,\footnote{The system is SYBASE and the vendor is Sybase; i.e., you purchase SYBASE from Sybase.} in a way that does not require modifications to any SYBASE servers or clients. The limitations of our approach are also discussed. After illustrating the feasibility of our approach with this specific example, we discuss in more general terms how it can be applied to other applications. X \section{Overview of our approach} \label{overview} X We were asked by a client to analyze the network security present in Sybase's client-server products and to develop solutions for its problems. The approach we used consists of these steps: \begin{itemize} \item Determine what security problems exist in the current implementation. X \item Determine what techniques can be applied to solving the problems. X \item Rank the importance of the security problems and of the advantages and disadvantages of each technique. X \item Choose one or more techniques to use in the solution. X \item Design and implement the solution using the chosen technique(s). \end{itemize} In Sections \ref{status-quo} through \ref{designing}, we discuss the application of this approach to the SYBASE problem, and in Section~\ref{performance}, we discuss the impact of our solution on performance. In Section~\ref{generalizing}, we use our experience with SYBASE as the basis of a more detailed overview of our approach. X \section{SYBASE's authentication technology -- the {\boldit status quo}} \label{status-quo} X \subsection{Standard SYBASE network access} X SYBASE clients access servers over the network using Sybase's Open Server protocol. The client side of this protocol is accessible to application developers in the SYBASE DB-Library, an API for establishing connections to servers, transmitting queries, and receiving responses. The server side of the protocol is likewise accessible in the SYBASE Server-Library API, which allows developers to implement Open Servers which accept connections from clients, receive queries, and transmit responses. In this paper, {\em SQL server} refers to a SYBASE SQL Server; {\em application server} refers to a server that is not a SQL server but uses the Server-Library API; and {\em Open Server} refers to any server that understands the Open Server protocol, i.e., either a SQL server or an application server. No distinction is made in the DB-Library between establishing a connection to an application server and establishing a connection to a SQL server. An Open Server can itself be a DB-Library client, i.e., a server can act as a client of another server. X A client connects to a server using the DB-Library's {\tt dbopen} call. Included in the information transmitted from the client to the server during the {\tt dbopen} is information which authenticates the client to the server: the username requesting the connection, and the associated password. In addition, the client can include {\em remote passwords,} consisting of a list of {\em\{ server name, password \}} couplets, to be used by the server if it needs to establish a connection to another server on the client's behalf.\footnote{Unfortunately, the remote password functionality is limited by the fact that the username to use on the remote server cannot be specified --- it must be the same as the primary username in the {\tt dbopen} call.} X When a SQL server receives an incoming connection request, it looks up the specified username in a SQL table of database users and verifies that the password given by the client matches the password in the table. If it does, then the connection is allowed; if not, an error is returned and the connection is terminated. X Since no distinction is made between connections to application servers and connections to SQL servers, application servers receive the same authentication information (username, password, remote passwords) as SQL servers. However, their use of the data is application-defined. In other words, password verification is not handled automatically by the Server-Library. X Typed data is transferred between clients and servers using Sybase's Tabular Data Stream (TDS) protocol, which deals with byte-order differences, differences in floating point representations, etc., for the application.\footnote{In other words, the TDS protocol is similar in function to Sun RPC's XDR standard \cite{XDR}.} Although the TDS protocol does not affect Sybase's authentication directly, it becomes relevant when considering how to improve the authentication, as discussed in Section~\ref{techniques}. X \subsection{Security problems with the Open Server protocol} X The Open Server protocol is vulnerable to four different attacks: \begin{description} \item[Password theft.] Client usernames, passwords and remote passwords are transmitted over the network in cleartext (i.e., without encryption). As a result, anyone who can read all packets on the network between a client and a server (``snoop'' on the network) can steal usernames and passwords and use them later to access servers illicitly. Such passive monitoring is very difficult to detect, and stolen passwords can remain a threat long after monitoring has ceased (since users often use the same passwords for long periods of time). X \item[Data theft.] Data sent between clients and servers can also be stolen, since the Open Server protocol does not provide any form of data encryption. This attack is completely passive (as opposed to password theft, which requires the active step of {\em using} stolen passwords before the attacker accrues any benefit) and therefore nearly impossible to detect. X \item[Unauthorized password use.] The Open Server protocol makes the assumption that servers can be trusted. However, an untrustworthy server (or the administrator of an untrustworthy server, or an attacker who has broken into a server) can use a client's remote passwords (or the password used to authenticate to the server, since users tend to use the same passwords for different servers) to gain illicit access to other servers. X \item[Data-stream modification.] There is no provision in the protocol for verifying data integrity. A clever attacker can insert data into the client-server data stream and (depending on the network technology and topology) may also be able to modify the data stream by deleting data from it and/or changing data in it. As network protocol cracking tools become more widely distributed, this attack becomes accessible to a wider range of attackers. \end{description} X \subsection{Administrative problems with SYBASE security} X A SQL server keeps its own table of usernames and passwords, independent of, and administered separately from, any enterprise-wide authentication database, e.g., a NIS passwd map or a Kerberos \cite{Kerberos} database. This complicates things for administrators, who would like to be able to easily change user passwords or revoke access, and for users, who would like to use only one username and password (each) for all of their authentication needs. Furthermore, when users are forced to remember multiple passwords, they tend to write them down, which significantly decreases the security of the system. X User passwords are stored on a SQL server in cleartext (as opposed to UNIX passwords, for example, which are stored in encrypted form). Therefore, any attacker managing to break into the SQL server with system administrator access immediately has access to all passwords and can subsequently use them for illicit access to the server (and possibly to others). X Finally, the Server-Library provides no built-in functionality for storing and verifying passwords, so application servers designed by an organization will have to keep independent authentication databases. X \subsection{A specific example: stealing SYBASE passwords} X When a DB-Library client initiates a connection to an Open Server, it sends a packet to the server with all of its login information in it (including the authentication information discussed above). The format of this packet is both uniform and predictable. Therefore, an attacker can easily determine how to detect such packets and extract from them usernames and passwords for a server. Furthermore, if the attacker waits long enough, it is likely that someone will log into the server over the network using the system administrator username and password, and once the attacker has them, he has unlimited access to the server. X This attack requires the ability to snoop on the network over which packets between the client and the server are transmitted. Ready-made tools for snooping are quite common and becoming more so --- if an attacker with network access wants to snoop, he probably can. Furthermore, even if all authorized hosts on a network are secure and therefore can't be used for snooping, an attacker can probably still snoop, e.g., by unplugging a workstation from the network and replacing it with a portable computer (with his ready-made snooping tools installed). X For example, in a recent demo, we were able to steal SQL Server usernames and passwords using a SPARCbook, the SunOS {\tt etherfind} command, and a {\tt Perl} script with only 21 lines of code. X \section{Potential solutions to SYBASE's network-security problems} \label{techniques} X The potential solutions we considered comprise three general approaches: network security, connection encryption and connection authentication. Specific solutions using each of these approaches are discussed below. X \subsection{Securing the entire network} \label{securing-network} X One technique is to eliminate the possibility of snooping on the network. There are two ways to do this: \begin{itemize} \item Make the network physically secure, so that an attacker cannot plug his own snooping hardware into it (or install a tap to see what's going over the network), and make all the machines on the network secure, so that an attacker cannot snoop from one of them, or \item Protect all data on the network with link encryption. \end{itemize} If the network is secured, then password theft, data theft and data modification are prevented. X Physically securing a network may be practical for a small network in a uniform, tightly administered environment. However, as the network gets larger and more distributed, it becomes much more difficult to establish a single (physical) network security policy, and even more difficult (financially and administratively) to enforce it. Furthermore, as the complexity of the network increases, it becomes more and more likely that a mistake will be made somewhere and that overall network security will be compromised as a result. Finally, physically securing the network is not an option if a portion of it is not controlled by the organization, e.g., if two offices in different locations are using one of the commercial Internet backbones for traffic between them. X Although products exist for encrypting all traffic on a network, such encryption is also impractical on a large network, for a number of reasons: \begin{itemize} \item Network encryption offerings tend to be expensive (in dollars, X as opposed to MIPS or network bandwidth, although they are X often expensive in those areas as well), and as the size of X the network increases, so does the cost of encryption (because X encryption hardware and/or software is usually required for X each machine on the network). \item Network encryption brings with it a significant administrative X overhead. The encryption technology itself must be managed, X and furthermore, the encryption can make it more difficult to X manage the network (i.e., it may prevent the licit network X snooping that is sometimes necessary in order to diagnose X network problems). \item A site with a heterogeneous network environment (in terms of the X networking technology used, and in terms of the kinds of X machines used) may find that no network encryption offering X will support the entire environment. \item Network encryption of all network traffic when only some of the X traffic needs to be protected is overkill, especially when the X traffic level on the network is high enough that the X encryption causes noticeable performance degradation. \item As with physical network security, network encryption of traffic X over a commercial Internet backbone may not be possible. \end{itemize} X \subsection{Connection encryption} X If securing or encrypting the entire network is not feasible, another technique is to secure individual Open Server connections from snooping, by encrypting individual connections in software. If done properly, this eliminates password theft, data theft and data modification, since passwords and data can be encrypted and signed to preserve their secrecy and integrity. The following sections discuss in more detail how connection encryption might be implemented. X \subsubsection{Application encryption} X An organization can implement DB-Library clients and application servers which encrypt/decrypt transmitted/received data. An advantage of handling encryption in the applications is that they can selectively choose which data needs to be encrypted; this may be important if a significant portion of the data being transferred is not secret. X This technique has some problems: \begin{itemize} \item Without access to the communication channel between the client and server, encryption must be done above the TDS protocol layer. As a result, all of the automatic type-conversion functionality of the Open Server protocol is unusable. X Current Sybase development libraries do not support access to the communications channel of the Open Server protocol below the TDS level,\footnote{Sybase plans to address this problem in a release some time in 1994.} so it seems unlikely that a TDS-capable encrypted Open Server connection can be implemented without extensive help from Sybase. X \item Even if it is possible to implement DB-Library clients and application servers which encrypt and decrypt data below the TDS layer, it is not possible to modify SQL servers to do the same,\footnote{SQL servers are sold in binary-only form by Sybase and the cost of obtaining their source code is prohibitive.} so encrypted communication with SQL servers is not possible. X \item Many organizations purchase ready-made DB-Library clients and application servers which cannot be recompiled or relinked. It is impossible to engage in encrypted communication with these, just as it is impossible to do so with SQL servers. \end{itemize} X \subsubsection{Socket-level encryption with mediators} X Treese and Wolman \cite{Treese} discuss rerouting client-server network connections through {\em application relays} to enhance security. One example they give is an application relay which accepts incoming X Window System connections for a user and asks the user if each connection should be permitted. Permitted connections are forwarded to the user's actual X server, using TCP protocol forwarding. X A similar approach can be taken to encrypt a SYBASE client-server connection. A DB-Library application can be fooled into connecting to an application relay running on the client's local machine, rather than to the remote server.\footnote{This is done by modifying the {\tt interfaces} file, which is used by Open Server clients to locate server hosts and port numbers, so that entries in it point to a server running on the local machine rather than to real servers on other hosts.} Since the relay is running on the same machine as the DB-Library application, communication between the two is not transmitted over the network and is therefore not vulnerable to snooping.\footnote{This assumes that the underlying operating system short-circuits network connections to the local host so that their data is not transmitted on the network (SunOS 4.1.3 meets this condition). If the OS doesn't short-circuit local connections, it can usually be fooled into doing so with routing table changes. Unfortunately, the intuitive method of using the loopback address ({\tt 127.0.0.1}) can't be used to force a short-circuited connection, at least not when dealing with SYBASE in particular, because there is a bug in SYBASE which prevents the loopback address from working in {\tt interfaces} files.} This relay then connects to another relay on the remote machine of the desired Open Server. The remote relay then connects to the Open Server (and again, communication between the two is local to the machine and therefore not transmitted over the network). The two relays pass all data between the client and server, but encrypt it before network transmission (and decrypt it after reception). This system is illustrated in Figure~\ref{dual-relays}. \begin{figure} \begin{center} \input dual-relays.figtex \end{center} \caption{Connection encryption with mediators} \label{dual-relays} \end{figure} X There are important differences between this system and Treese and Wolman's application relays. First, two relays are required, one on the client machine and one on the server machine. Second, the primary purpose of Treese and Wolman's system is to allow limited, policy-restricted connections through a firewall, whereas the purpose of the encrypting relay system is to provide a protected communication path between a client and a server.\footnote{The system proposed here can be made to work through a firewall by placing a third relay on the firewall machine in the middle of the encrypted communication channel.} To distinguish between Treese and Wolman's one-relay approach and the two-relay approach presented here, we refer to our relays as {\em mediators.} A mediator which accepts a connection from a client and forwards it through an encrypted connection to another mediator is called an {\em outbound mediator,} and a mediator which does the opposite, accepting an encrypted connection from another mediator and forwarding it to a server, is called an {\em inbound mediator.} X This technique has none of the problems of application encryption. Furthermore, it is very generalized; a mediator implementation to encrypt Open Server connections will work with only slight modifications with other types of TCP connections as well. X However, it, too, has its problems: \begin{itemize} \item Open Server connections aren't always carried over TCP/IP networks with machines at both ends that can be made to do TCP protocol forwarding easily. Different mediators have to be implemented for each network type supported. Application encryption, on the other hand, is implemented on top of the Open Server protocol, which means that it should be easily portable to different network types. X \item There may be significant performance degradation caused by forcing all client-server communication to pass through two extra processes. X \item Since encryption takes place below the application level, all data must be encrypted, even data that does not have to be kept secret. This is a problem if encryption of large amounts of non-secret data causes performance degradation. \end{itemize} X \subsubsection{Open-Server-level encryption with mediators} X If, instead of implementing mediators at the TCP level as described above, they are implemented on top of the Open Server libraries,\footnote{The Open Server libraries provide specific functionality, ``TDS pass-through mode,'' that a server can use to transparently pass data between a client and another server.} then they will be portable to all network types that the libraries support. X However, this increased portability is obtained at the expense of bringing back one of the major problems of application encryption. Until the Open Server libraries support access to the communication stream, proper encryption of data by an Open-Server-level mediator can be done only with extensive help from Sybase. X \subsection{Connection authentication} X Rather than relying on the Open Server username/password mechanism to authenticate users, a stronger authentication system such as Kerberos or SPX \cite{SPX} can be integrated into the system. X If the authentication system chosen does not require private data to be sent by a client to a service during authentication and if it obviates the need for separate authentication databases in Open Servers (both Kerberos and SPX meet these conditions), then password theft and unauthorized password use attacks are prevented. X Just as with connection encryption, authentication can take place at three levels: application, socket and Open Server. X \subsubsection{Application-level authentication} X Strong authentication can be layered on top of the DB-Library and Server-Library, and DB-Library clients and Server-Library servers can be modified to use the new authentication. However, just as with application encryption, this technique will not work with SQL servers or with third-party clients and servers that cannot be relinked or recompiled. X \subsubsection{Socket-level mediator authentication} X If a mediator can be made to understand only enough of the Open Server protocol to be able to distinguish the username and password sent at the beginning of an Open Server data stream, then mediators can be used to do strong authentication. This has some of the same disadvantages as socket-level mediator encryption: different mediators have to be implemented for the different network types supported by the Open Server libraries, and performance may suffer because client-server communication must pass through two extra processes. X Furthermore, since the Open Server libraries support multiple versions of the Open Server protocol, the mediators will have to know how to recognize different versions of the protocol and change their technique for locating the username and password appropriately. Also, the mediators may have to be updated when new protocol versions are released. X \subsubsection{Open-Server-level mediator authentication} X Mediators can be implemented using the Open Server libraries to receive incoming connections, initiate outgoing connections, perform necessary authentication using Open Server remote procedure calls, and then enter pass-through mode so that the end client and server can communicate with each other. This technique does not suffer from most of the problems of application authentication and socket-level mediator authentication; however, the performance impact of forcing client-server communication to go through extra processes is still a concern. X \subsection{Summary} X Table~\ref{advantage-matrix} summarizes the advantages of the various techniques discussed above. \begin{table} \caption{Advantages of techniques for securing SYBASE} \label{advantage-matrix} \begin{center} \setlength{\myboxwidth}{143pt} \begin{tabular}{l|c|c|c|c|c|c|c|} \cline{2-8} X & Securing & \multicolumn{3}{c|}{Encryption} & \multicolumn{3}{c|}{Authentication} \\ X & the & Appli- & Socket & Open & Appli- & Socket & Open \\ X & network & cation & & Server & cation & & Server \\ \hline \mybox{ Prevents password theft } & $\surd$ & $\surd$ & $\surd$ & $\surd$ & $\surd$ & $\surd$ & $\surd$ \\ \hline \mybox{ Prevents unauthorized password use } & & & & & $\surd$ & $\surd$ & $\surd$ \\ \hline \mybox{ Prevents data theft } & $\surd$ & $\surd$ & $\surd$ & $\surd$ & & & \\ \hline \mybox{ Prevents data modification } & $\surd$ & $\surd$ & $\surd$ & $\surd$ & & & \\ \hline \mybox{ Eliminates Open Server authentication databases } & & & & & $\surd$ & $\surd$ & $\surd$ \\ \hline \mybox{ Works with all networks supported by Open Server } & $\surd$ & $\surd$ & & $\surd$ & $\surd$ & & $\surd$ \\ \hline \mybox{ Easily supports other application protocols } & $\surd$ & & $\surd$ & & & $\surd$ & \\ \hline \mybox{ Easily supports multiple Open Server protocol versions } & $\surd$ & $\surd$ & & $\surd$ & $\surd$ & & $\surd$ \\ \hline \mybox{ Works with preexisting clients and servers } & $\surd$ & & $\surd$ & $\surd$ & & $\surd$ & $\surd$ \\ \hline \mybox{ Supports full TDS functionality of Open Server libraries } & $\surd$ & & $\surd$ & & $\surd$ & $\surd$ & $\surd$ \\ \hline \mybox{ Causes negligible performance degradation } & & & & & $\surd$ & & \\ \hline \end{tabular} \end{center} \end{table} X \section{Ranking problems, advantages and disadvantages} \label{ranking} X We chose a simple system for ranking the problems, advantages and disadvantages listed in Table~\ref{advantage-matrix}. By negating the disadvantages and treating them as advantages, we were able to do all of our ranking on one scale. We chose simply to classify each item in the table as either required or desirable. Our ranking is shown in Table~\ref{groupings}. \begin{table} \caption{Prioritization of solution advantages} \label{groupings} \begin{center} \setlength{\myboxwidth}{3.5in} \begin{tabular}{l|c|c|} \cline{2-3} X & Required & Desirable \\ \hline \mybox{ Prevents password theft } & $\surd$ & \\ \hline \mybox{ Prevents unauthorized password use } & & $\surd$ \\ \hline \mybox{ Prevents data theft } & & $\surd$ \\ \hline \mybox{ Prevents data modification } & & $\surd$ \\ \hline \mybox{ Eliminates Open Server authentication databases } & & $\surd$ \\ \hline \mybox{ Works with all networks supported by Open Server } & $\surd$ & \\ \hline \mybox{ Easily supports other application protocols } & & $\surd$ \\ \hline \mybox{ Easily supports multiple Open Server protocol versions } & & $\surd$ \\ \hline \mybox{ Works with preexisting clients and servers } & $\surd$ & \\ \hline \mybox{ Supports full TDS functionality of Open Server libraries } & $\surd$ & \\ \hline \mybox{ Causes negligible performance degradation } & & $\surd$ \\ \hline \end{tabular} \end{center} \end{table} X Our prioritization was, for the most part, client-driven, since we were asked to design a solution to SYBASE's problems by a client with specific requirements. As shown in the ranking table, their primary security concern was theft of passwords by network snoopers, and their other concerns were related to usability in their environment and interference with Open Server library functionality. X \section{Choosing techniques} \label{choosing} X Comparing the requirements in Table~\ref{groupings} with each of the techniques in Table~\ref{advantage-matrix}, we saw that two of techniques, securing the network and Open-Server-level mediator authentication, satisfy all the requirements. We and our client both rejected securing the network as a valid solution, for the reasons given in Section~\ref{securing-network}. Therefore, we chose Open-Server-level mediator authentication, using Kerberos version 4 as our strong authentication system, as the basis for SecureBase. X \subsection{Why we chose Kerberos} X We chose Kerberos version 4 as the basis for our solution for two primary reasons: \begin{itemize} \item Stable, reliable implementations of Kerberos version 4 exist, both in freely redistributable and commercial forms. We can bundle a free implementation with our product for sites that are not already running Kerberos, or refer them to a commercial vendor, or use an existing Kerberos installation. X \item Kerberos is currently more of a standard, both {\em de facto} (through widespread use) and {\em de jure} (through standards-body and vendor acceptance), than any of the other available strong authentication technologies. It is not likely to lose this acceptance in the near future. \end{itemize} X Although most vendors and standards bodies endorse Kerberos version 5 instead of version 4, primarily through the Open Software Foundation Distributed Computing Environment \cite{DCE}, we felt that version 5 offerings are not yet stable enough or available widely enough to base a short-term product (which SecureBase was intended to be) on it. In any case, migration of a product and its users from Kerberos version 4 to Kerberos version 5 is likely to be less arduous than migration from any other strong authentication technology to Kerberos version 5. X \subsection{Enhancements to our primary solution} X In addition to meeting our requirements, our chosen technique also met several of our desirables. However, several desirables were still missing. We dealt with them as follows: \begin{description} \item[Data-theft and -modification prevention.] We are working with Sybase in an effort to find out enough about the Open Server protocol that we will be able to encrypt a TDS pass-through mode communication stream in our mediators. We are also considering adding socket-level mediator encryption underneath our Open-Server-level mediator authentication. We have decided to postpone work in this area until the next version of SecureBase. \item[Easy support for other application protocols.] Although our choice to implement Open-Server-level mediators rather than Socket-level mediators means more work for us if we want to add authentication to a system besides SYBASE, it also guarantees easy portability to all supported Open Server networks and platforms as well as automatic support for multiple Open Server versions. We felt that these advantages, which greatly impact the usability of the product, were compelling enough to force us to choose Open-Server-level mediation. \item[Negligible performance degradation.] The use of mediators is unavoidable when adding strong authentication to existing applications. However, applications that can be relinked or recompiled can be modified to do strong authentication directly, at the application level. We therefore decided to provide application authentication functionality in addition to our mediator authentication functionality. In other words, we would provide an API for developers to use to do the same authentication that the mediators do, but directly, rather than through mediators. As a result, performance degradation can be reduced for applications that can be relinked or recompiled. \end{description} X \section{SecureBase's design} \label{designing} X Our design consists of several components: \begin{itemize} \item An API library for use by DB-Library clients to establish Kerberos-authenticated connections to Kerberos-capable Open Servers, including inbound mediators on remote hosts. A client using this API is a {\em SecureBase client.} \item An API library for use by Server-Library servers ({\em SecureBase servers}) to authenticate connections from SecureBase clients. \item A SecureBase ``drop-in replacement library'' for the standard DB-Library. This library replaces a small number of DB-Library functions with SecureBase versions with the same names. Developers of DB-Library clients can link their applications against the drop-in replacement library to get SecureBase authentication without any source-code modifications. \item A mediator application which uses the other API libraries to do SecureBase authentication as either an inbound or outbound mediator (or both; for example, a mediator running on a firewall might do Kerberos authentication of incoming connections and then establish an authenticated connection to a server on the other side of the firewall). \item Utilities for installing and administering the system. \end{itemize} SecureBase's complete detailed design is beyond the scope of this paper. However, the design of some of its components is illustrative of general techniques for layering strong authentication on top of third-party applications. These design components are discussed below. X \subsection{The SecureBase protocol} X The SecureBase protocol is implemented as a series of Open Server remote procedure calls made by the SecureBase client to authenticate and transmit necessary information to the SecureBase server. Like the Open Server protocol, the SecureBase protocol is query-response-based (i.e., all data transfer consists of a request from the client to the server followed by a response from the server to the client). X When a SecureBase client wants to log into a server, it follows these basic steps: \begin{enumerate} \item Connect to the server. X \item Transmit a Kerberos authenticator to the server. X The Kerberos authenticator includes a block of data, given to the client by the Kerberos server, that can be decrypted only by the server. This data is what authenticates the client to the server. The authenticator also includes a session key which can be used for data encryption between the client and the server. X The server responds with a message indicating whether the authenticator was accepted as valid and whether the client should transmit the client's passwords. X \item If requested by the server, transmit the client's password and/or remote passwords, encrypted using the session key contained in the authenticator. X Since backward compatibility with existing clients and servers and a smooth migration path from old-style SYBASE security to SecureBase security are required, it may be necessary for Open Server authentication databases to remain in place for some period of time while SecureBase is being phased in. In that situation, SecureBase must interoperate with those authentication databases, which means, for example, that an inbound mediator will need to be given a client's password in addition to a Kerberos authenticator, so that the mediator can log into the Open Server for the client using the password. Similarly, remote passwords may be needed. Therefore, when a client transmits a Kerberos authenticator to the server, the data sent by the server in response includes flags telling the client whether or not to also transmit the client password and/or remote passwords. If requested, they are encrypted before transmission so they are not vulnerable to snooping. X The server responds with an acknowledgement. X \item Tell the server that SecureBase authentication is complete. Again, the server responds with an acknowledgement. \end{enumerate} These steps imply four message types that a client may transmit to a server: {\em authenticate,} {\em password,} {\em remote\_passwords,} and {\em done.} Furthermore, one additional message, {\em change\_password,} is supported. If a client wishes to change its password in the authentication database of a SQL Server protected by a mediator, but does not wish to do so using the SYBASE SQL {\tt sp\_password} stored procedure (which will cause his new and old passwords to be sent over the network in cleartext), it can send a {\em change\_password} request to the mediator. This request contains the client's old and new passwords, encrypted in the session key for protection from snooping, and tells the mediator to change the client's password in the SQL Server's authentication database. X The protocol is summarized by the state table in Table~\ref{state-table}. \begin{table} \caption{SecureBase protocol state table} \label{state-table} \begin{center} \begin{tabular}{l@{}l} \begin{tabular}{l} \strut \\[0.29in] \rotate{\hbox{States}} \\ \end{tabular} & \begin{tabular}{l||c|c|c|c|c|} \multicolumn{1}{l}{} & \multicolumn{5}{c}{Client messages} \\ \cline{2-6} \multicolumn{1}{l||}{} & {\em authenticate} & {\em password}& {\em remote\_passwords} & {\em change\_password}& {\em done} \\ \hline \hline \multicolumn{1}{|l||}{\bf start} & {\tt rd\_auth} & & & & \\ \multicolumn{1}{|l||}{} & \goto{auth.} & \goto{end} & \goto{end} & \goto{end} & \goto{end} \\ \hline \multicolumn{1}{|l||}{\bf auth.} & & {\tt rd\_pw} & {\tt rd\_rpws} & {\tt ch\_pw} & {\tt ck\_done} \\ \multicolumn{1}{|l||}{} & \goto{end} & \goto{auth.} & \goto{auth.} & \goto{auth.} & \goto{done} \\ \hline \end{tabular} \end{tabular} \end{center} \end{table} Valid messages are shown across the top of the table, and server states are shown down the left side. Each intersection shows the action that is performed (if any) and the state entered after the action. If the action fails, the server immediately jumps to the {\bf end} state. X The {\bf start} state is entered automatically when an incoming connection request is received. The {\bf end} and {\bf done} states are not shown because when the server enters either of those states, the protocol exchange has been completed (and therefore none of the messages listed in the state table can be received). The {\bf end} state causes an immediate termination of the connection. The behavior of the server in the {\bf done} state, which represents the end of authentication (rather than the end of the connection) is application-dependent. For example, an inbound mediator entering the {\bf done} state will connect to the Open Server for which it is mediating and go into pass-through mode, whereas a SecureBase server entering that state will begin processing client data requests. X The behavior of the {\tt rd\_auth}, {\tt rd\_pw}, {\tt rd\_rpws} and {\tt ch\_pw} actions should be obvious. On the other hand, the {\tt ck\_done} action is perhaps less obvious. It verifies that the client has transmitted all necessary information (e.g., if the client password and remote passwords were requested, it verifies that they were sent), and if so, succeeds; otherwise, it fails, which causes the connection to terminate. X \subsection{The SecureBase libraries} X The three SecureBase libraries previously mentioned are {\tt krbsybdb}, the client library; {\tt krbsybsrv}, the server library; and {\tt sybdb}, a drop-in replacement library for the standard Sybase DB-Library. X \subsubsection{Client library} X SecureBase clients link against the {\tt krbsybdb} library in addition to Sybase's {\tt sybdb} DB-Library. Low-level access to the internals of the SecureBase protocol are provided; however, most DB-Library clients will not have to utilize it, since their needs are met by the {\tt krb\_dbopen} function, which parallels, and takes the same arguments as, the DB-Library's {\tt dbopen} function (in fact, {\tt krb\_dbopen} becomes {\tt dbopen} in the drop-in replacement SecureBase library). X The {\tt krb\_dbopen} function extracts the authentication data of the client from the structure passed into it, and uses that data to authenticate to the server using the protocol described above. X \subsubsection{Server library} X SecureBase servers link against the {\tt krbsybsrv} library in addition to Sybase's {\tt srv} Server-Library. Because of the way Open Servers work, we cannot provide a server interface to SecureBase as transparent as the {\tt krb\_dbopen} client interface (nor can we provide a drop-in replacement for Sybase's Server-Library). In the current implementation, SecureBase servers must handle the steps of the authentication protocol themselves; i.e., they must support the state table in Table~\ref{state-table}. Individual {\tt krbsybsrv} functions are provided for reading an authenticator, reading the client's encrypted password, etc. However, a later version of SecureBase will probably provide more transparent server authentication. X \subsubsection{Drop-in replacement library} X The drop-in replacement library is constructed by merging the standard Sybase {\tt sybdb} library, the Kerberos libraries ({\tt krb}, {\tt des} and {\tt com\_err}), and the {\tt krbsybdb} library into a single library, a new version of {\tt sybdb}. The names of several {\tt sybdb} functions are changed in the library object files, and those functions are replaced with their {\tt krbsybdb} counterparts. The new {\tt sybdb} library can replace the old one and will appear identical to developers of DB-Library applications. X \subsection{The SecureBase mediator} X The basic functionality of the mediator application has already been discussed. A particular mediator invocation accepts incoming connection requests, either using Open Server authentication or SecureBase authentication, and then connects to another Open Server, again using Open Server authentication or SecureBase authentication. If all authentication is successful, the mediator enters pass-through mode for client and server and passes all further data transparently. This basic functionality is augmented by several features which may be interesting to designers of similar mediators for other applications. X \subsubsection{Multiple outgoing authentication modes} X A mediator invocation can choose whether or not to tell clients connecting to it to transmit their passwords and remote passwords. If they are requested, then they are used in the outgoing connection to connect to the desired Open Server (as described previously, the mediator should be running on the same machine as the Open Server, so that the passwords are not transmitted over the network in cleartext). X If passwords are not requested, the mediator can determine the password to use to connect to the Open Server in a number of different ways. In {\em SQL} mode, it connects to the desired SQL Server as the system administrator, asks it what the user's password is, and uses that password to log the user in. In {\em dynamic} mode, it does the same thing, but changes the user's password to a random, presumably unguessable password immediately after logging the user in. Dynamic mode is the recommended mode, since it makes the authentication database in the SQL Server obsolete, and at the same time makes the passwords in it unguessable, so all connections to the server must go through the mediator. X \subsubsection{Trusted Kerberos principals} X The mediator allows certain Kerberos principals to be treated as ``superusers'' by allowing any connection authenticated with one of the principals on the trusted access-control list (ACL) to specify any username when logging into the desired Open Server. This has a number of advantages; the two most significant are: \begin{itemize} \item Since all connections through the mediator can be logged, including the Kerberos principal making the connection and the username used to connect to the desired Open Server, a detailed audit log of administrative access to the Server can be produced. With standard Open Server authentication, the server knows only that someone logged in with the administrator username and password; if many people have the password, there is no accountability. \item Since administrative access is controlled by an ACL, the administrator password does not have to be given out, and administrator access for a particular individual can be revoked by editing the ACL rather than by changing the administrator password and distributing it to everyone else. \end{itemize} X \section{Performance issues} \label{performance} X We measured the effect of SecureBase authentication on Open Server connections by measuring the time required to perform the following operations: \begin{itemize} \item Transferring a large amount of data from a SQL Server to a X client (data transfer rate). \item Transmitting a short query to a SQL server and receiving a short X response (packet latency). \item Logging into a SQL server (login latency). \end{itemize} We performed each of these operations in three different connection modes: \begin{itemize} \item A direct connection from a standard DB-Library client to a X standard SQL Server. \item A connection from a standard DB-Library client to an outbound X mediator to an inbound mediator to a standard SQL server. \item A connection from a SecureBase client to an inbound mediator to X a standard SQL server. \end{itemize} Our results are shown in Table~\ref{performance-table}, normalized to the control case (standard DB-Library connection to a standard SQL server). \begin{table} \caption{Performance measurements of SecureBase} \label{performance-table} \begin{center} \begin{tabular}{lccc} X & Data transfer & Packet latency& Login latency \\ DB-Library client to SQL Server & 1.00 & 1.00 & 1.00 \\ DB-Library client to outbound mediator & 2.58 & 1.10 & 1.20 \\ SecureBase client to inbound mediator & 2.23 & 1.32 & 1.33 \\ \end{tabular} \end{center} \end{table} In addition, for the SecureBase client, we performed an additional login test in which an existing Kerberos ticket cache was used for all logins, rather than obtaining new tickets from the Kerberos server for each login. The performance improvement was negligible. X Our performance testing confirmed our hypotheses that transmitting data through two additional processes (i.e., the outbound and inbound mediators) would cause significant performance degradation, and that reducing the number of additional processes to one (by connecting directly to the inbound mediator) reduces, but does not eliminate, the performance degradation. X However, some of the results of our testing were surprising to us, and we cannot adequately explain them. Why should the latency of a single packet of data be greater when going through one mediator than when going through two? Similarly, why does it take longer to log in when going through one mediator than when going through two? Finally, why was there no noticeable performance improvement when we used an existing Kerberos ticket cache for all logins instead of getting new tickets each time? X It is possible that we need to modify our testing environment in order to better emulate production use of SecureBase. For example, our Kerberos server is on the same machine as our SQL server, and all testing took place on a single lightly loaded ethernet segment. Loading the test network more, placing the servers on different machines, and placing the servers and clients on different subnets might tell us more. Furthermore, we need to do a more detailed analysis of where the most time is actually being spent. X \section{Generalizing the technique} \label{generalizing} X Although SecureBase's code is not easily portable to other applications besides SYBASE, because it uses the Open Server libraries extensively, the general concepts applied by SecureBase toward the problem of securing SYBASE are easily generalizable to other relational database systems and other client-server applications. X Any attempt to add strong authentication to an existing network application should follow the steps listed in Section~\ref{overview}. The following sections discuss a general approach to some of those steps. X \subsection{Locating security problems} X The set of potential security problems for a network application is relatively small. Since SYBASE is relatively wide open to network attacks on its security, the problems identified in Section~\ref{status-quo} (i.e., password theft, data theft, data modification, unauthorized password use, and independent authentication databases) can be used as a ``base set'' when examining other applications. It is usually quite straightforward to determine if an application is vulnerable to one of these attacks --- unless the documentation for the application says otherwise, it {\em probably} is. X \subsection{Listing potential solution techniques} X The techniques proposed for securing SYBASE (in Section~\ref{techniques}) are a good base set to consider when analyzing how to secure another application. However, some of those techniques may not be applicable in all cases. Here's what to look for when considering them: \begin{description} \item[Securing the network.] The applicability of securing the network is independent of the application, since physical network security is (mostly) independent of the applications run on it. Instead, consider the feasibility of securing the network, given the problems outlined in Section~\ref{securing-network}. \item[Application authentication.] Do you have access to the source code for the both the client(s) and server(s) to which you want to add authentication? If they use a vendor-provided API, can you use that API to transmit and receive arbitrary authentication data (encoded, if necessary, in a form that the API can transmit)? \item[Application encryption.] In addition to all of the requirements for application authentication, do you have access to the data stream at a low enough level that encrypting it will not interfere with the application protocol? If not, do you have access to the specifications for the application protocol, and can you handle necessary data conversions yourself so that the vendor API doesn't have to? \item[Protocol-level mediator authentication.] Are there vendor-provided APIs for both clients and servers? Can they interoperate in the same process, i.e., can a process be both a client and a server? Is there support for a server gatewaying between a client and another server? Is there a way to trick clients and servers so that connections are routed through your mediator? As for application authentication, can you transmit arbitrary authentication data within the bounds of the protocol? \item[Protocol-level mediator encryption.] In addition to all of the requirements for protocol-level mediator authentication, can you encrypt the data stream safely as for application encryption? \item[Socket-level mediator authentication.] Can you extract authentication data from a TCP stream? Is the format of authentication data in the stream likely to change from version to version of the application protocol? Are you going to have to support different network types? Can you trick clients and servers into rerouting connections? \item[Socket-level mediator encryption.] Are you going to have to support different network types? Can you trick clients and servers into rerouting connections? \end{description} When listing potential solution techniques, it is important to spell out the problems each technique solves and its advantages and disadvantages. This greatly simplifies the tasks of ranking and choosing the techniques to use. X \subsection{Ranking problems, advantages and disadvantages} X The ranking of problems, advantages and disadvantages should answer several questions. Which problems are important to solve, and which can be ignored or left for later? How important is having each advantage? How important is {\em not} having each disadvantage? Implicitly or explicitly, the rankings state the requirements of the desired solution. X Someone setting out to improve the security of an application generally has in mind some problems which {\em must} be solved. Therefore, a good first ranking step is to establish a category for definite requirements and decide what to put in it. Then, decide how much granularity is needed when ranking the non-requirements. X Often, a simple ``requirements'' vs. ``desirables'' ranking, such as the one used for SecureBase, will be sufficient. However, if more precision is needed (e.g., if it's necessary to approach a manager and ask for a decision about which approach to take, and he wants the values of the various approaches quantified), it may be necessary to rank the desirables more precisely, e.g., on a numerical scale. X \subsection{Choosing appropriate techniques} X The ranking should make it easy to choose which technique(s) to use. If it doesn't, then you should redo the ranking until it does. The ``ranking'' step should in fact be considered part of the ``choosing'' step, and should be the larger part of it. X If one technique meets all of the requirements specified by the rankings, then use it. Otherwise, figure out how multiple techniques can be integrated to meet the requirements together. X \section{Future work} \label{future-work} X We hope to develop the ideas presented in this paper further in a number of different areas: \begin{itemize} \item Adding support for data encryption and/or integrity X verification. \item Porting to other RDBMS's. \item Porting the API libraries to non-UNIX platforms. \item Exploring some of the other techniques described above, e.g., X using socket-level mediation instead of protocol-level X mediation. \item Developing a more generalized approach which avoids the problems X described above, so that it is easier to add authentication to X other applications. \item Porting to other network applications. \end{itemize} X Furthermore, we hope to improve our performance analysis of SecureBase, as described in Section~\ref{performance}. X \bibliographystyle{plain} \bibliography{secpaper} X {\small\noindent Terms that are printed in caps or initial caps in this paper may be trademarks of Digital Equipment Corporation; the Massachusetts Institute of Technology; Sun Microsystems, Inc.; Tadpole Technology, Inc.; Sybase, Inc.; UNIX Systems Laboratory; or another manufacturer.} X %\newpage %\section*{Availability} % %Because of our current product priorities, development of SecureBase %is currently suspended until the beginning of 1994 or later. However, %we are willing to distribute binary-only demonstration versions of the %product, for SPARC machines running SunOS 4.1, with no support. %Interested parties should contact the author. X \end{document} SHAR_EOF $shar_touch -am 1017203995 'secpaper.tex' && chmod 0664 'secpaper.tex' || echo 'restore of secpaper.tex failed' shar_count="`wc -c < 'secpaper.tex'`" test 56484 -eq "$shar_count" || echo "secpaper.tex: original size 56484, current size $shar_count" fi exit 0