Validation and authentication for Notes® and Domino®

Whenever a Notes® client or 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/Renovations (the client) wants to access Mail-E/East/Renovations (the server).

  1. Mail-E reads the Renovations public key from Mail-E's ID file. According to the first rule in the preceding list, Mail-E trusts the public key assigned to Renovations.
  2. Randi sends Mail-E information in her user ID. Mail-E reads Randi's user ID for the certificate issued by Renovations to East. Mail-E uses the Renovations public key, which it now trusts, to verify that the East certificate is valid. According to the second rule in the preceding list, 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/Renovations to Marketing. Mail-E uses the East/Renovations public key to verify that the Marketing/East/Renovations certificate is valid. Again, the second rule states that Mail-E now trusts the public key assigned to Marketing/East/Renovations.
  4. Mail-E reads Randi's user ID for the certificate issued by Marketing/East/Renovations to Randi. Mail-E uses the Marketing/East/Renovations public key, which it now trusts, to verify that Randi's certificate is valid. According to the third rule in the preceding list, 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.