S 2.208 Planning of the domains and certificate hierarchy of Lotus Notes

Initiation responsibility: Head of IT Section, IT Security Management

Implementation responsibility: IT Security Management, Administrator

A Notes system consists of one or more Lotus Notes servers and a number of Notes and/or Web clients. The individual servers in a Notes system can be assigned to individual Notes domains. Domains determine the administrative boundaries and the validity of security settings (e.g. access controls), just as in other network operating systems. In addition a separate namespace is erected through every domain. Planning of the Notes domains and the namespace defined through them is therefore very important.

A domain corresponds with a Notes directory and can, roughly speaking, be viewed as a tool for distributing e-mail. The namespace of a domain can be structured hierarchically into organisational units, so that users, groups and servers that are brought together in a domain can be further subdivided. The way a domain is divided must be tailored to the requirements of the organisation. However, it is recommended that the division reflects the organisational structure.

E-mail communications can be protected under Lotus Notes through the use of encryption and digital signatures (see S 5.85 Use of encryption procedures for Lotus Notes e-mail). To distribute the cryptographic keys, a certificate hierarchy (public key infrastructure, PKI) should be set up. This can be independent of domain planning so that several independent certificate hierarchies could exist in one Notes domain or one certificate hierarchy could cover several domains.

When planning domains, it is important to consider whether a single or a multiple domain concept is appropriate.

A single domain concept possesses the following advantages:

• All the users' e-mail addresses possess the same domain identifier ( user@domain). It is not necessary for the sender to have a knowledge of Notes domain membership as is necessary where multiple domains are used within an organisation.

• Administration is significantly simplified, as only one Name and Address Book (NAB) needs to be maintained. Where several domains are used, then the NAB will additionally contain the connection entries and domain definitions which determine the interfaces of a given domain with the other domains. These must be maintained individually for every domain. With a single domain concept, this work does not have to be performed.

A multiple domain concept possesses the following advantages:

• Large numbers of users are easier to administer in several domains since performance declines as the size of the NAB increases and administration also becomes less straightforward. If the NAB is also replicated on clients (e.g. for mobile users), the increased amount of storage space required can be a problem, as can the longer replication time, especially with a slow connection. The use of several domains and hence several NABs therefore has advantages and also offers a certain protection against failure.

• Often organisational structures are not homogeneous and are therefore difficult to map onto exactly one Notes domain. In particular, it is often sensible or in fact imperative that individual areas are kept administratively separate, for example if different security provisions have to be implemented or country-specific characteristics, such as language or characters sets, need to be considered. This separation can only be achieved by using a multiple domain concept.

• Where organisational units are merged together, previously independent Notes domains are continued as integration would require a lot of administrative effort or use of the established namespace is to be continued.

• Special domains which can be used to isolate or set up boundaries between domains can be created, for example, test domains, domains for software development and domains with dial-in access.

When planning the domain concept, it must be borne in mind that subsequent changes to the domain model, although possible, are generally very costly in terms of the administrative effort entailed since all the servers and users affected by a domain change must be relocated within the Notes domains. It may also be necessary to undergo recertification and to convert database ACLs.

When planning certificate hierarchies, in general the following points should be borne in mind:

• A distinction must be made between Notes certificates and the Internet certificates (X.509 certificates) used by Notes. It may therefore be necessary to administer two certificate hierarchies in parallel.

• Only Notes certificates and no Internet certificates can be used to certify Notes users (Notes ID).

• The granting and monitoring of access authorisations (including between different domains) in Lotus Notes is based on the Notes certificates.

• Trust relationships between different certificate hierarchies (without a common certification entity) can be registered by effecting cross-certification (recognition of certificates issued by other bodies). The ill-considered granting of cross-certificates (usually these can be automatically generated when an unknown certificate is "discovered") reduces system security. This applies both to Notes certificates and also to X.509 certificates. It is also easy for users to create cross-certificates in personal local address books. On the other hand, only an authorised Administrator may create cross-certificates in the Name and Address Book.

• Only Internet certificates can be used to identify users when access occurs via the Lotus Notes Web interface.

• Notes certificate structures can be flat or hierarchical. In a flat certificate structure there is one certification authority which issues the certificates for all the users. In a hierarchical certificate structure there are several certification authorities, whereby the certificates issued by one certification authority are also signed by a higher level certification body.

Flat certificate structures are simpler to administer, whereas hierarchical structures possess the advantage that it is possible to delegate administration (thus, for example, departments can certify new users themselves). This also means that individual organisational units can issue and administer their own certificates.

• The certificate hierarchy must be planned. Among other things it is necessary to specify which certificates are issued and who may certify what. Areas of competence and responsibilities must be planned.

Setting up a certificate hierarchy is generally less of a technical problem than an organisational and policy problem. An appropriately long planning phase is therefore needed, in which all the parties involved either technically or organisationally participate and which is promoted by a policy approved by all those involved.

Additional controls:

• Is the domain planning documented?

• Is a certificate infrastructure (PKI) already operated?

• Can or must the PKI be used to issue X.509 certificates?