cr1 consists of the following components:
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
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.
an executable program,
file, which is
a database of shared keys, optionally encrypted with a
a daemon process that manages the key database
containing the log file
Shared keys can also be created for users.
can share a key with
or with user
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:
When the authentication exchange is successfully completed,
the user on the client
connects to the service on the server.
The connection server on the client requests the
service from the port monitor on the server.
is an internal service that
determines the scheme that is protecting a service,
then passes the information to the client.
service returns a message
informing the connection server that
the service is protected by cr1.
Once the client receives the name of the scheme,
it caches the information for future use, so
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.
© 2004 The SCO Group, Inc. All rights reserved.
UnixWare 7 Release 7.1.4 - 22 April 2004