SECURITY

Validation and authentication for Notes and Domino
Whenever an IBM® Lotus® Notes® client or IBM® Lotus® Domino™ server attempts to communicate with a Domino server to replicate, route mail, or to access a database, two security procedures use information from the client or server ID to verify that the client or server is legitimate. Validation establishes trust of the client's public key. If validation occurs successfully, authentication begins. Authentication verifies user identity, and uses the public and private keys of both the client and the server in a challenge/response interaction.

Rules that guide trust of public keys

Validation uses these three rules to establish the trust of a public key. Domino validates the client that is trying to access the server and the server that the client is trying to access.

1. Trust the public key of any of the server or client's ancestors in the hierarchical name tree because the ancestor's public key is stored in the server or client's ID file.

2. Trust any public key obtained from a valid certificate issued by any of the server or client's ancestors in the hierarchical name tree.

3. Trust any public key certified by any trusted certifier and belonging to one of the certifier's descendants.

How validation and authentication work

This example describes how validation and authentication work together to ensure the security of the system. In this example, user Randi Bowker/Marketing/East/Acme (the client) wants to access Mail-E/East/Acme (the server).

1. Mail-E reads the Acme public key from Mail-E's ID file. According to the first rule above, Mail-E trusts the public key assigned to Acme.

2. Randi sends Mail-E information in her user ID. Mail-E reads Randi's user ID for the certificate issued by Acme to East. Mail-E uses the Acme public key, which it now trusts, to verify that the East certificate is valid. According to the second rule above, if the certificate is valid, Mail-E trusts the public key assigned to East.

3. Mail-E then reads Randi's user ID for the certificate issued by East/Acme to Marketing. Mail-E uses the East/Acme public key to verify that the Marketing/East/Acme certificate is valid. Again, the second rule states that Mail-E now trusts the public key assigned to Marketing/East/Acme.

4. Mail-E reads Randi's user ID for the certificate issued by Marketing/East/Acme to Randi. Mail-E uses the Marketing/East/Acme public key, which it now trusts, to verify that Randi's certificate is valid. According to the third rule above, if the certificate is valid, Mail-E trusts the public key assigned to Randi.

5. After Mail-E establishes trust of Randi's public key, the authentication process begins.

6. Mail-E sends a random number challenge to Randi.

7. Randi's workstation encrypts the challenge with her private key and sends the newly encrypted number back to Mail-E.

8. Mail-E uses Randi's public key to decrypt the response. If this yields the original challenge, Mail-E knows Randi is who she claims to be.

9. The process is then reversed. Randi's workstation validates Mail-E's public key by processing Mail-E's certificates and then uses the challenge/response procedure just described to authenticate the server.

See also