When a client establishes a new connection this is done in userent::Connect. The userent class knows the secret token and if it is still valid. An authenticated bind is attempted. If it fails the client removes the tokens.
The request arrives in the ServerLWP routine where it is calling RPC2_GetRequest. This time the hook to get the keys is the routine GetKeysFromToken. The secret token included with the clients bind request is decrypted with the tokens found in auth2.tk and auth2.tk.BAK. The latter allows the server password to be changed without the server having to be restarted.
The fileserver will attach a current protection subdomain (see below) to a ClientEntry when it executes the CheckSemantics calls. This is only done for authenticated connections.
It is appropiate to end this section with a short discussion of the things that need to be done to get kerberos to work with Coda. While the detailed names and calling conventions will remain to be sorted out the following summarizes the task. We start by very briefly reviewing Kerberos authentication.
Kerberos authentication is very similar to Coda authentication, with one difference: the kerberos server, or Key Distribution Center gives a Ticket Granting Ticket (TGT) which can be used to get specific session keys for a variety of servers from the TGS (Ticket Granting Service). Once a user has authenticated to the KDC using kinit, is given a TGT which kerberized applications use to get session keys for client server connections.
The client is issues a session key encrypted with the secret the server shares with the KDC as well as an unencrypted session key.
Instead of the dialogue with the auth2 server and the functioning of clog the following will need to be done.
These modifications seem minor. Warning: the sizes of a variety of structures may well be different in Kerberos and Coda.
There are a variety of security holes that we need to plug in Coda:
Do we know of any other holes?