Coda File System

(Illustration by Gaich Muramatsu)

• News
• About
• Downloads
• Mailing lists
• Bugs
• FAQ
• Documentation
• Development
• Research
• Wiki

3. Authentication to the fileserver

3.1 Authenticated connections in Venus and Vice

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.

3.2 Kerberos for Coda

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.

1. The user authenticates to the Kerberos KDC and acquires a TGT.
2. When Venus establishes a new connection to the server it checks if it has a session key for this user. If not, it tries to acquire one using the TGT which should be available on the machine. If the session key is present but has expired it does the same. There is a standard routine in libkrb.a to get this session key.
3. It now proceeds to connect to the fileserver using the Kerberos DES encryption routine and the session key acquired from the KDC in the normal fashion of auth2 bind.
4. The server must acquire the shared secret between the KDC and the server to decrypt the packet coming from the client. Again there is a standard routine in libkrb.a to get this key. DES decryption will then give the client's request.
5. We now proceed as before using the kerberos session key instead of the auth2 session key.

These modifications seem minor. Warning: the sizes of a variety of structures may well be different in Kerberos and Coda.

3.3 Security holes to plug

There are a variety of security holes that we need to plug in Coda:

• the most serious issue that needs to be addressed is to use authenticated connections for the callbacks. A client should have an option to be started and not accept OPENKIMONO connections for callbacks. There seems no difficulty in implementing this.
• It would be a good idea to kerberize the volutil and
• advice monitor connections
• dispose of the insecure tcp socket for mariner and replace it with authenticated RPC2 connections.
• the failure package similarly should establish secure connections only

Do we know of any other holes?