Sophie: coda-doc-5.2.0-4mdk noarch

coda-doc-5.2.0-4mdk.noarch.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
 <TITLE> Coda Authentication and Protection: Authentication and secure connections. </TITLE>
 <LINK HREF="sec-3.html" REL=next>
 <LINK HREF="sec-1.html" REL=previous>
 <LINK HREF="sec.html#toc2" REL=contents>
</HEAD>
<BODY>
<A HREF="sec-3.html">Next</A>
<A HREF="sec-1.html">Previous</A>
<A HREF="sec.html#toc2">Contents</A>
<HR>
<H2><A NAME="s2">2. Authentication and secure connections. </A></H2>

<P>
<P>The system of authentication and encryption of data going between
clients and servers is very close to that employed by Kerberos 5, see
???. 
<P>The key ingredients in the mechanisms are as follows:
<UL>
<LI> <EM>Shared secret cryptography</EM>: in the protocols it is assumed
in numerous places that the two <EM>principals</EM> on a connection share
a "secret" key, allowing the sender to encrypt data and the receiver
to decrypt it.  The acquisition of shared keys is involved since they
cannot be sent over the net in the clear. </LI>
<LI> <EM>Establishing secure connections</EM>: this comprises a
mechanisms to establish a secure connections if the two parties share
a secret key and a public <CODE>ClientIdent</CODE>. Secure means
<EM>authenticated</EM> and <EM>encrypted</EM>. </LI>
<LI> <EM>Authentication protocol</EM>: this protocol is a variant of the
Needham Schroeder authentication protocol.  It allows the generation
of a shared secret, called a session or handshake key for use between
client and fileserver based on communication with an
<EM>authentication server</EM>.  The result of the an authetication
session is that the client acquires a session key on the basis of
supplying a correct password. This key is initially only known to the
authentication server and client. </LI>
<LI> The authentication server and the fileserver share a secret and
can communicate the session keys for certain clients securely.  In
this way the fileserver can set up a secure connection with the
client. </LI>
</UL>
<P>Let us look at the details.
<P>
<H2><A NAME="ss2.1">2.1 Encryption</A>
</H2>

<P>
<P>The files rpc2.h and secure.c in the RPC2 package contain the
cryptographic routines.  For export reasons only RPC2_XOR is in use,
but it would be easy to use DES too. 
<P>A bit of cleanup seems to be needed, also in the random number
routines. 
<P>
<H2><A NAME="ss2.2">2.2 Secure and authenticated connections</A>
</H2>

<P>
<P>RPC2 allows to bind to a server (i.e. set up a connection) in 4 ways:
<DL>
<DT><B>OpenKimono:</B><DD><P>neither authenticated nor encrypted
<DT><B>AuthOnly:</B><DD><P>authenticated but not encrypted
<DT><B>HeadersOnly:</B><DD><P>authenticated and headers of RPC packets are
encrypted
<DT><B>Secure:</B><DD><P>authenticated and RPC packets are encrypted.
</DL>
<P>The security implications for the different types of connections are
discussed in Satya's paper, as well as the algorithm employed in the
bind routine (RPC2_NewBinding, rpc2a.c).
<P>Of interest here is that the encryption type is given to the bind
routine as a variable. A small amount of cleanup in secure.c should
help to make DES encryption an easy switch.  It would be interesting
to measure the effect of encryption on performance.
<P>
<H2><A NAME="ss2.3">2.3 Authentication tokens </A>
</H2>

<P>
<P>In the preceeding two subsections we did not explain how a shared
secret between the server and client can be established.  The
following three methods of acquiring such a secret are in place:
<P>
<OL>
<LI> upon authentication the auth server and the client can share
the password of the user to establish a secure connection</LI>
<LI> in the final stages of authentication the auth server can send
the client a session key, which it also shares with the server</LI>
<LI> venus and the server use the session key from the
authentication protocol to establish a secure connection</LI>
</OL>
<P>Let us go into detail for case 1.  Coda employs the clog program to
get a session key. clog looks up the username in <CODE>/etc/passwd </CODE>
and tries a secure binding with the auth server using the username as
ClientIdent and the password, which it got from the user, as the
Secret.  It then executes a standard bind request to the auth server.
<P>The auth server receives this request (using RPC2_GetRequest in
auth2.cc) which points to the routine PWGetKeys as a means to acquire
the shared secret for the bind routine. 
<P>PWGetKeys is the heart of password authentication.  The viceid for the
user is looked up (see the documentation regarding the protection
database) and password file auth2.pw is opened to find her
password. The password can be decrypted with the FileKey ("dreuss ").
At this moment PWGetKeys returns and the client and server share a
secret.  (XXX: the routines copying passwords copy buffers of a fixed
length and might not deal with passwords which are too short
gracefully). 
<P>It tries a host listed as an argument to clog to find an auth server
or cycles through the hosts in vstab.  If the binding is successful
this is taken as a guarantee that the password was correct, and clog
proceeds by placing the AuthGetTokens rpc.  The server
<P>The next rpc which clog makes invokes AuthGetTokens which sets the
last used time one the ui component of the clientident and returns two
tokens to the client:
<UL>
<LI> The clear token ( <CODE>ctoken</CODE>): contains
<OL>
<LI>  the handshake key (also called the session key)</LI>
<LI>  an authhandle (always -1)</LI>
<LI>  a begin time (always 0)</LI>
<LI>  a final time (always </LI>
<LI>  the viceid for the user</LI>
</OL>
</LI>
<LI> the secret token ( <CODE>stoken</CODE>): containing:
<OL>
<LI> the above information </LI>
<LI> random fields</LI>
</OL>

The secret token is encrypted with the TokenKey which is obtained from
auth2.tk. </LI>
</UL>

Of course this information is returned over the connection secured by
the users password. 
<P>We now enter the last stage of clog: it must tell Venus what about the
two keys it acquired for the user. This is the routine
U_SetLocalTokens, avenus.cc. This routine passes the two tokens to
Venus through a pioctl.  (similar routines get the tokens or remove
the tokens). 
<P>
<H2><A NAME="ss2.4">2.4 Bugs to fix and things to improve </A>
</H2>

<P>
<P>
<UL>
<LI> There seems to be a problem with the handling of
U_SetLocalTokens in vproc_pioctl.cc (VIOCSETTOK): it gets the ue for
which it enters the token from the packet passed up by pioctl.  This
is wrong. The tokens were acquired for the user listed as an argument
to clog and these are not necessarily the same. Remove the mess and
let the routine get the user entry from the clear token (and perhaps
an extra parameter passed with the pioctl). </LI>
<LI> GetPathName in avenus.cc should return /coda by default not
/cmu. </LI>
<LI> Clean up the code a bit</LI>
<LI> Check that the cycling through hosts in vstab is working</LI>
<LI> Figure out if  the encryption of passwords works with variable
length keys.</LI>
<LI> Check that passwords can be of variable length</LI>
<LI> Check that clog uses the username (not the client userid) and
that if it uses the id a translation localuid to viceid is maintained
appropiately. This will need some modifications in venus too, but is
important for cells and system administration. </LI>
<LI> in GetPWKeys the statting of the auth.pw file is done at the
wrong moment</LI>
<LI> the "feature" that auth2 checks for the presence of "new" auth2
binaries in <CODE>/vice/bin/auth2</CODE> seems over the top and causes system
administration nightmares. This code should just be removed. </LI>
<LI> It seems pretty mysterious that the "direct assigment of fields
doesn't work" (user.cc in coda-src/venus).  I would like to know why.</LI>
<LI> user.cc contains some routines that call abort.  In fact these
routines should be removed so that the compiler can check if those
culprits are ever called. </LI>
</UL>
 
<P>
<HR>
<A HREF="sec-3.html">Next</A>
<A HREF="sec-1.html">Previous</A>
<A HREF="sec.html#toc2">Contents</A>
</BODY>
</HTML>