Public Key Encryption

Public key encryption uses two keys, one to encrypt and the other to decrypt. The relationship between the two keys is mathematically complex, so it is virtually impossible to infer the value of one key from the other. Consequently, one key can be made public without the risk of exposing the other key.

The network entity that will receive messages generates a key pair and distributes the public key. Services that send encrypted messages must do so with the public key, and the holder of the private key can then decrypt the messages.

If you have the public key, you can encrypt messages to a client that possesses the matching private key, and only the private key can decrypt the messages encrypted with the public key. Since only one person has the private key, only one person can decrypt your messages.

Conversely, a sender can encrypt data using the private key. The recipients of this message use the public key to decrypt the message. If the decryption is successful, the recipient can be sure that the message was encrypted with the corresponding private key. In this case many people can decrypt the message, but only the holder of the private key could have generated the message.

Authentication Requirements

Before you can authenticate to eDirectory, you need a credential and a signature. You can obtain these by logging in to the network.

The credential is a data structure made up of a validation period and other user identification information. The signature is the result of a private-key encryption of the credential data.

In response to a login request, authentication services sends the client agent a private key that has been encrypted and stored in eDirectory. The client agent receives the password from the user. Nothing more is requested of the user from this point on. The client agent decrypts the private key.

The client agent then creates the credential with data unique to this session and encrypts it with the private key, thus creating the signature. Once the signature is created, the private key is erased from memory, but the signature and credential are retained. The following figure shows the principal items used to form the signature.

Figure 3-1 Items Used to Form a Signature

In many systems, a signature is itself the authentication mechanism and accompanies a message to its destination. This usage of a signature typically enables the recipient to verify that the message originated from its purported sender, by virtue of the fact that the receiver can decrypt it.

However, Authentication Services extends the concept of a signature further by using proofs. A proof is data derived from both the signature and the message. It is transmitted on the network with the request or message. Its use adds an extra measure of security by keeping the signature itself off the network.

Authentication Process

After constructing the credential and the signature, the client agent can authenticate itself to an eDirectory server on the network.

The client agent’s request for client-server authentication is accompanied by a proof, which is constructed from values derived from both the signature and the request data (message) itself. The following figure shows the principal items used to construct the proof.

Figure 3-2 Items Used to Form a Proof

A proof is a part of all authentication dialogues. A proof ties the clients’ signature to both the current request (message) and the current session, thus making each proof unique to the request it accompanies. The proof also makes it unnecessary to transmit the signature.

The request for authentication is transmitted to Authentication Services (a part of eDirectory) along with the proof and the unencrypted credential (see the following figure.) Then Authentication Services mathematically verifies that the proof is valid. The proof always assures the recipient that the message has not been modified since it was sent.

Figure 3-3 Items Used to Confirm Authentication

To summarize, a valid authentication provides the following guarantees:

The following figure summarizes the steps involved in initial authentication.

Figure 3-4 Logging in and Authentication Summary

Background Authentication

Background authentication with other participating services on the network can be accomplished in a manner similar to the initialization process. In background authentication, the client agent already has the authentication materials (credential and signature) on hand, and wants to authenticate itself to a new service. For example, the client agent may be seeking an attachment to a server. Since the client agent has already acquired the authentication materials, it can perform the authentication to the server without disturbing the user.

The client agent begins by sending a request to the desired service. In response, the service sends the client agent a challenge, or nonce. The nonce is a random number generated for the current transaction only. The same nonce is not used again.

The client agent computes a proof of the credential and nonce using the signature, and then sends the nonce, the credential, and the proof to the service.

The service then verifies that the proof was legitimately generated from the nonce and credential. This establishes the client’s authenticity. The nonce ensures that the message was created for the current request and is not data from another session. The service returns a confirmation. The following figure shows the exchange that occurs during background authentication.

Figure 3-5 Background Authentication Summary

Password Changing in eDirectory

A special exchange is required in order for a client agent to change an object’s password. Changing a password involves the client agent replacing the current encryption of the private key. The new private key encryption is generated with the new password. The generation and encryption of the private key occurs at the workstation, but the encrypted key is stored with eDirectory. It is not stored at the user’s workstation.

The exchange begins with the user supplying the old and new passwords to the client agent. The client agent then asks eDirectory for the server’s public key, and it is returned to the client agent. The agent then asks for the user’s private key. The private key is returned from eDirectory with an accompanying nonce.

The client agent then encrypts the private key with the new password. The nonce, the old and new passwords, and the new private key encryption are placed into a message buffer that is encrypted using the server’s public key, so that the combined data can be safely transmitted to the eDirectory Server and decrypted by the server using the server’s matching private key.

When the client agent sends the request to change the password, the server is able to decrypt the message containing the nonce, the old and new passwords, and the user’s newly encrypted private key. This is sufficient verification that the transaction is valid, so the server completes the password change and sends a confirmation of the password change back to the client agent. The following figure shows the steps required to change the password.

Figure 3-6 Change Password Summary

Changing Public and Private Key Pairs

Each object in eDirectory has its own private/public key pair that is generated at the time the object is created. If conditions warrant it, a key pair can be changed. Setting or changing the public/private key pair for an object requires a special exchange between the client agent and Authentication. The exchange assumes that the client desiring to make the change has already authenticated itself to eDirectory. The client desiring to make the key pair change must have sufficient access privileges sufficient to change the values of the target object’s Private Key and Public Key attributes.

The exchange begins once the user gives the name and password of the object that will receive the new key pair. The object’s Tag Data Store (TDS) information is obtained. The TDS consists of a certificate, credential, and signature. The certificate consists of the name of the user object, the user’s public key and other information. The credential and signature have been discussed previously.

The client agent checks to see whether the object is currently connected and authenticated with the server performing the key pair update. If it is not, then an authentication is established. Next, the server’s public key and a nonce are obtained. The servers public key is used later to encrypt the key pair update request buffer prior to requesting that the pair be set.

The client agent then generates a new key pair with the intent of submitting it as the key pair for the target object. The new private key (of the new key pair) is encrypted with the target object’s user password, and is included in the request data used to create a proof. The data for the proof includes the nonce, the object’s ID, the password, the new encrypted private key, and the new public key. The server public key obtained earlier is used to encrypt this proof. The final step is to submit the request to set the new key pair for the target object. The following figure shows the steps required to set the object’s key pair.

Figure 3-7 Set Key Pair Summary