There are two challenges to centrally managing Lotus Notes ID files:
- No administrative password reset capability:
It is impossible to administratively reset passwords on Lotus Notes ID files. The ID files are encrypted using each user's current password and must be decrypted using the same current password before they can be re-encrypted using a new password.
An administrative password reset is defined as a password change made using an administrative ID and password and without the user's current password. From this definition, it is clear that administrative password resets are just not possible for Lotus Notes ID files.
Note that it is possible to change an ID file password -- just not administratively reset one.
- No built-in facility to gather or distribute ID files:
Lotus Notes ID files may be physically stored anywhere -- on a user's PC (typically in C:\Notes\Data), on a network share, or even on removable media. Many copies of the same ID file may have to be managed. For example, A manager may have copies of the same ID file on her primary PC, her notebook, her assistant's PC, her home PC and on a flash memory device.
IBM/Lotus does not provide any mechanism for gathering or distributing ID files in Lotus Notes versions prior to 8.5. Starting with Notes 8.5, IBM/Lotus added a mechanism which is remarkably similar to the PSNS DLL and ID file repository introduced by Hitachi ID Systems several years earlier. Consequently, there is no simple, standard mechanism for a server such as Password Manager to deliver updated ID files back to their user/owners unless all user PCs have Notes 8.5 or later and all Notes servers run Notes 8.5 or later.
Lotus Notes is probably the most widely deployed PKI system today, despite pre-dating standards such as X.509. The challenges described above apply not only to Lotus Notes, but also to most public key infrastructure (PKI) systems, since they generally maintain encrypted certificate files on user PCs.
Many organizations address these two challenges by storing copies of each user's Lotus Notes ID file in a central repository. This may be a file share, a Lotus Notes NSF database or some other storage system. Normally, a matching password is either stored in the repository alongside each ID file or else ID files are issued (and stored) with an implicit password, such as the user's login ID or a fixed, well-known string.
Starting with version 8.5 of Lotus Notes (all clients and servers must run this), there is a native repository built into Lotus Notes itself.
Using the central repository (built-in or custom-built), administrative password resets are simulated by extracting an old copy of the user's ID file from the repository, opening it with the old password, also from the repository, making a non-administrative password change and delivering the modified ID to the user. Different implementations vary in regards to how the repository is managed and how ID files are delivered to users.
Since users may change the contents of their ID file, the copy of their ID file in the repository may become obsolete. This leads to the third major challenge with managing Lotus Notes ID files:
- ID files in the repository become obsolete:
The content of a user's ID file may change over time. Users may attach new encryption keys or cross-certifications to their ID files. Users change names (for example, when they marry). In each of these cases, the ID file must change to match.
This is a problem in an environment where password resets on ID files are simulated using a repository of old ID files, other than the repository built into Notes 8.5 (or later) servers, when used in conjunction with Notes 8.5 (or later) clients. The ID files stored in the repository may be quite old and not contain changes that happened since enrollment, such as cross certifications and name changes. If a user's password is "reset," -- i.e., the old ID file retrieved from the repository, changed and delivered to the user -- such changes will be lost.
Lotus Notes Key Escrow
One solution offered by IBM/Lotus to resolve problems that arise when users forget their own passwords is key escrow. Key escrow was introduced with Lotus Notes R5, and works as follows:
- Setup and initial registration:
- A recovery database is created, to hold a copy of each user's ID.
- Recovery IDs are created in that database. These IDs will later be able to, singly or jointly, recover individual users' lost or disabled Notes ID files.
- The recovery IDs are attached to each certifier ID.
- Users are sent an e-mail request to "accept" the recovery information into their ID files, and to enable harvesting, which will place a copy of their ID file in the recovery database.
- Unlocking an ID file when users forget their password:
- One or more recovery administrators access the user's ID file from the recovery database, and use their own ID files and passwords to generate a recovery password.
- The recovery password is given to the user.
- The user types the recovery password, and is able to open the ID file.
ID file recovery does work, but has serious operational problems:
- It depends on user acceptance and successful registration.
Unregistered users will not be supported by the process. Users must take several steps to register, and in some cases even users who wish to cooperate (by accepting the recovery message and enabling harvesting) will fail to perform these steps correctly.
- It is tied to one or more recovery IDs. If these IDs are tied
to human administrators, and those administrators leave without
providing their password, then the entire registration database
becomes obsolete, and the process must be started from scratch.
- There is no audit trail of ID file recovery. If an administrator
can get a copy of a user's ID file, especially without using the
recovery database (which can be configured to log access attempts),
then the administrator will be able to "recover" the ID and
perform actions as the user in question -- effectively impersonating
- Recovery passwords are, in effect, static passwords applied to
each enrolled ID file. They are hard to guess (16 random
hexadecimal digits), but once revealed to a user, manager or
administrator, they can be thought of as a legitimate password to
the user's ID file, which never changes. Static passwords
violate security policy in most organizations.