cr1 Bilateral Authentication Scheme

cr1 components

cr1 consists of the following components:

an executable program, /usr/lib/iaf/cr1/scheme
the /etc/iaf/cr1/keys file, which is a database of shared keys, optionally encrypted with a master key
keymaster(1Mbnu), a daemon process that manages the key database
/var/iaf/cr1, containing the log file log

The cr1 privileged user can create a key to be shared by the local system and any remote machine on the network. The privileged user is the owner of the keys file. Once a shared key is created for the two principals, the key management daemon stores the key in the key database, then uses a cryptographic key--called the master key--to encrypt the keys in the database. The keys in the database are re-encrypted every time a new key is added.

Shared keys can also be created for users. For example, bob on system1 can share a key with system2 or with user joe on system2. When a key is created for a user, the name of the client user and the system to which the user wants access must be specified. The privileged user can create a shared key for any local user. A non-privileged user can create shared keys for their individual login name.

When a user attempts to run a service on the client, the command that executes the service initiates the following sequence of actions:

The connection server on the client requests the reportscheme service from the port monitor on the server. reportscheme is an internal service that determines the scheme that is protecting a service, then passes the information to the client.
The reportscheme service returns a message informing the connection server that the service is protected by cr1.
NOTE: Once the client receives the name of the scheme, it caches the information for future use, so reportscheme need not be called every time the connection server requests a connection to the service.
The connection server then requests a connection to the service from the port monitor on the server.
Both the connection server and the port monitor invoke cr1. On the client, the connection server calls cr1 to play the role of the responder in the authentication exchange (cr1 on a client is called the responder because it responds to the server's requirement that cr1 be used). On the server, the port monitor calls cr1 to play the role of the imposer (cr1 on the server is called the imposer because it protects a local service by imposing the use of the cr1 protocol on the client machine).
The responder searches various local databases and sends pertinent information to the server. Included in that information is the responder's effective identity (that of the local user) and the name of the client machine. Also included in the message is a unique token, which the responder sends as a challenge to cr1 on the server.
The responder's message is received by cr1 on the server (the imposer). After the imposer receives the responder's message, it retrieves the shared key from its key database and verifies that the key properly decrypts the message. It then sends the responder a message that includes the responder's token; by returning the token, the imposer proves its identity to the responder. The imposer's message also includes another unique token, which the imposer sends to challenge the responder.
The responder receives the message and validates its contents, proving that the sender properly decrypted the first message using the key known only to the two parties. The responder then sends a third message that includes the unique token provided by the imposer.
The imposer receives the third message and verifies that the token it included in the previous message was successfully decrypted and returned, proving that the responder is an active participant in the conversation.

When the authentication exchange is successfully completed, the user on the client connects to the service on the server.