The Protocol Used to Verify the Authentication

Local Login - When a user presents his userid and password to a client, the client may proceed with the local login mechanism. That is, the client may have a local password file and compare a one-way function of the user supplied password to the encrypted password stored locally. Alternatively, the client may not store passwords locally and may need to request the one-way encryption of the user's password from a centralized database that contains usernames and one-way encryptions of the passwords. This is usually the same database that contains the network public-key database. Along with authenticating the user locally, the client also receives from the public-key database the public and private keys for the user. The private key is encrypted using the user's password. (The vulnerability created by this is discussed below.) The client decrypts the private key using the user-supplied password. The client stores the secret key (probably encrypted under a client secret key, although this was not verified in the literature) for future server requests. It should be noted that the user's password is never sent across the network.

Remote Login and Client/Server Requests - The protocol used to authenticate users who request these two types of accesses is the same. The protocol used to authenticate the client, acting on behalf of the user, is shown below.

For any further requests between the client and server:

1. & 2. The client, acting on the user's behalf, authenticates the user to the server. To accomplish this, the client:

1. creates a conversation key (CK) to be kept secret between the client/user and the server. CK is DES encrypted using the secret key (SK) independently generated by the client and server (an explanation of how this key is generated is below).
2. defines a window of time that specifies how long CK can be used.
3. provides a current timestamp.
4. specifies window+1.

3. The server decrypts the conversation key (CK) by using the secret key (SK). The server can then decrypt the timestamp, the window and the window+1 using the conversation key. These values are stored by the server into a credential table. The window+1 value helps to prevent a correct chance guessing by an intruder a correct timestamp/window combination. (Details on this type of attack were not provided).

The file server knows that the user is who he claims to be, because according to [GS91,p. 284]:

• The packet that the user sent was encrypted using a conversation key.
• The only way that the user could know the conversation key would be by generating it, using the server's public key and the user's secret key.
• To know the user's secret key, the workstation had to look up the secret key in the public key database and decrypt it correctly.
• To decrypt the encrypted secret key, the user had to have known the key that it was encrypted with - which is, in fact, the user's password.

5. The client stores ID and CK to use for future requests to the server. The ID/CK pair stored on the client is deleted when the user logs out.

6 & 7. For future requests, the client authenticates the user to the server by sending the ID, and a current timestamp encrypted using CK. The server decrypts the timestamp, uses the ID to find the entry in the credential table, and determines if the current timestamp is not beyond the original timestamp+window. If the timestamp is valid, the server verifies the authentication of the user, and sends back to the client the timestamp-1, encrypted using CK. The client knows this response came from the server, because the server had the correct value for timestamp-1, and encrypted this value with the correct key.