#!/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 <mshort@eurynome>.
#
# 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:  https://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@,3<Y(#$S.2 Q-SD@,3,Y(#(T.2 R,3D@,C0Y(#DY.3D@.3DY.0HR(#(@
M," S("TQ(# @," P(# N,# P(#<@," P"@D@-#,Y(#(T.2 T,SD@,3<Y(#,U
M.2 Q-SD@,S4Y(#(T.2 T,SD@,C0Y(#DY.3D@.3DY.0HR(#(@," S("TQ(# @
M," P(# N,# P(#<@," P"@D@-#,Y(#,V.2 T,SD@,S$Y(#,U.2 S,3D@,S4Y
M(#,V.2 T,SD@,S8Y(#DY.3D@.3DY.0HR(#$@," S("TQ(# @," P(# N,# P
M(#<@,2 Q"@DP(# @,RXP,# @,3(N,# P(#(T+C P, H)," P(#,N,# P(#$R
M+C P," R-"XP,# *"2 R,3D@,C$T(#,U.2 R,30@.3DY.2 Y.3DY"C(@,2 P
M(#,@+3$@," P(# @,"XP,# @-R Q(#$*"3 @," S+C P," Q,BXP,# @,C0N
M,# P"@DP(# @,RXP,# @,3(N,# P(#(T+C P, H)(#$W.2 R-#D@,3<Y(#,Q
M.2 Y.3DY(#DY.3D*,B Q(# @,R M,2 P(# @," P+C P," W(#$@,0H)," P
M(#,N,# P(#$R+C P," R-"XP,# *"3 @," S+C P," Q,BXP,# @,C0N,# P
M"@D@,SDY(#,Q.2 S.3D@,C0Y(#DY.3D@.3DY.0HR(#(@," Q("TQ(# @," P
M(# N,# P(#<@," P"@D@,C,Y(#$V.2 R,SD@-#(Y(#$Q.2 T,CD@,3$Y(#$V
M.2 R,SD@,38Y(#DY.3D@.3DY.0HR(#(@," Q("TQ(# @," P(# N,# P(#<@
M," P"@D@-#4Y(#0R.2 T-3D@,38Y(#,S.2 Q-CD@,S,Y(#0R.2 T-3D@-#(Y
M(#DY.3D@.3DY.0HR(#$@,2 Q("TQ(# @," P(#0N,# P("TQ(#$@, H)," P
M(#$N,# P(#0N,# P(#@N,# P"@D@,C@Y(#$W.2 R.#D@,C Y(#DY.3D@.3DY
M.0HR(#$@,2 Q("TQ(# @," P(#0N,# P("TQ(#$@, H)," P(#$N,# P(#0N
M,# P(#@N,# P"@D@,C4T(#(X-" Q.#0@,C@T(#DY.3D@.3DY.0HR(#$@,2 Q
M("TQ(# @," P(#0N,# P("TQ(#$@, H)," P(#$N,# P(#0N,# P(#@N,# P
M"@D@,S(T(#(X-" S.30@,C@T(#DY.3D@.3DY.0HT(#$@," Q,B P("TQ(# @
M,"XP,# P," T(#D@-S$@,3<Y(#0Q.2!C;&EE;G0@;6%C:&EN90$*-" Q(# @
M,3(@," M,2 P(# N,# P,# @-" Y(#<V(#,Y.2 T,3D@<V5R=F5R(&UA8VAI
M;F4!"C0@,2 R(#$R(# @+3$@," P+C P,# P(# @,3(@,C@@,3<Y(#$Y.2!R
M96QA>0$*-" Q(#(@,3(@," M,2 P(# N,# P,# @," Q,B V-B Q-SD@,S,Y
M($1"+4QI8G)A<GD!"C0@,2 R(#$R(# @+3$@," P+C P,# P(# @,3(@-C @
M,3<Y(#,U-R!!<'!L:6-A=&EO;@$*-" Q(#(@,3(@," M,2 P(# N,# P,# @
M," Q,B R." S.3D@,S,Y($]P96X!"C0@,2 R(#$R(# @+3$@," P+C P,# P
M(# @.2 S-R S.3D@,S4W(%-E<G9E<@$*-" Q(#(@,3(@," M,2 P(# N,# P
M,# @," Q,B R." S.3D@,3DY(')E;&%Y 0HT(#$@,B Q,B P("TQ(# @,"XP
M,# P," P(#$R(#8P(#$W.2 R,3<@*&!@;W5T8F]U;F0!"C0@,2 R(#$R(# @
M+3$@," P+C P,# P(# @,3(@-C @,3<Y(#(S-2!M961I871O<B<G*0$*-" Q
M(#(@,3(@," M,2 P(# N,# P,# @," Q,B U,B S.3D@,C$W("A@8&EN8F]U
M;F0!"C0@,2 R(#$R(# @+3$@," P+C P,# P(# @,3(@-C @,SDY(#(S-2!M
M961I871O<B<G*0$*-" Q(# @,3(@," M,2 P(# N,# P,# @-" Q,B U,2 R
M.#D@,3,Y($5N8W)Y<'1E9 $*-" Q(# @,3(@," M,2 P(# N,# P,# @-" Y
M(#4S(#(X.2 Q-S4@8V]N;F5C=&EO;@$*-" Q(# @,3(@," M,2 P(# N,# P
M,# @-" Y(#0Q(#(X.2 Q-3<@;F5T=V]R:P$*-" Q(# @,3(@," M,2 P(# N
M,# P,# @-" Q,B V,R R.#D@,C<T(%5N96YC<GEP=&5D 0HT(#$@," Q,B P
M("TQ(# @,"XP,# P," T(#D@,C,@,C@Y(#(Y,B!L;V-A; $*-" Q(# @,3(@
K," M,2 P(# N,# P,# @-" Y(#4Y(#(X.2 S,3 @8V]N;F5C=&EO;G,!"C(@
X 
end
SHAR_EOF
  $shar_touch -am 1017203995 'dual-relays.fig.uu' &&
  chmod 0664 'dual-relays.fig.uu' ||
  echo 'restore of dual-relays.fig.uu failed'
  shar_count="`wc -c < 'dual-relays.fig.uu'`"
  test 2760 -eq "$shar_count" ||
    echo "dual-relays.fig.uu: original size 2760, current size $shar_count"
fi
# ============= dual-relays.figtex ==============
if test -f 'dual-relays.figtex' && test X"$1" != X"-c"; then
  echo 'x - skipping dual-relays.figtex (file already exists)'
else
  echo 'x - extracting dual-relays.figtex (text)'
  sed 's/^X//' << 'SHAR_EOF' > '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
