S 4.124 Configuration of authentication mechanisms with browser access to Lotus Notes

Initiation responsibility: Head of IT Section, IT Security Management

Implementation responsibility: Administrator, users

Where browsers are used to access a Lotus Domino server a decision must be made as to which authentication procedure should be used on the Web interface. Several different authentication mechanisms are available on the Web interface.

1. No authentication: anonymous access

2. Authentication via user name and password

3. Authentication via client certificates

It is therefore necessary to ascertain first of all whether anonymous access to the server needs to be allowed. This will be the case if public data is also to be made accessible to users who are not Notes users. However, it is recommended holding public data on a special server which contains exclusively public data. Anonymous access can be allowed for such a server. Anonymous access should generally not be allowed on a production server, so that authentication is always required on the Web interface.

The type of authentication procedure to be used depends on several factors. The following factors need to be considered here (including as part of a risk assessment):

1. Authentication via user name and password

With the HTTP protocol it is possible to have users authenticated through the input of user name and password. The browser reads in the data and sends it on to the server (in this case the Domino Web Server module) on every request.

The following security-relevant aspects must be considered when using this authentication procedure:

1. Without SSL protection on every request the authentication data is converted into 7-bit code and transmitted openly (in base64 format), so that it can easily be intercepted and discovered by third parties. Web access should therefore always be effected with SSL (see S 4.123 Configuration of SSL-protected browser access to Lotus Notes).

2. The Internet password chosen must be different from the Notes ID password. If an attacker succeeds in learning the Internet password and that password is also used for the Notes ID, then an attacker can also use the Notes ID (assuming he can obtain access to it). With the Notes ID the attacker can then access the Lotus Domino system via a Notes client and use the extended functionality of Notes clients, for example, to export certificates and change the Notes ID password.

3. In older versions of Notes (versions prior to 4.6) the Internet password is stored in the personal document in such away that identical passwords result in the identical value (an "unsalted hash" is used). As a result, it is very simple to search for and find identical passwords. Older versions of Notes should therefore be avoided if possible.

This authentication mechanism exhibits inherent weaknesses in its use over unprotected connections. Therefore access to individual databases should be restricted for users (see safeguard S 4.125 Instituting restrictions on access to Lotus Notes databases with browser access), if they are authenticated using this mechanism.

2. Authentication via client certificates

The following security-relevant aspects must be considered when using this authentication procedure:

1. In order that client certificates can be used, SSL (version 3) must be used with client authentication. Since all browser connections should be protected with SSL, this does not constitute a restriction.

2. Every user (or, to be more precise, every user's browser) must be provided with a client certificate. This means either operating a separate certification server or setting up a trust relationship for an external certification authority. In addition the certificates need to be administered. This implies extra work and presupposes that both Administrators and users have the appropriate expertise. In particular, the users must be familiar with the management functions for certificates in the browser.

3. The security of authentication depends essentially on the local security of the Web client (see S 4.127 Secure configuration of browser access to Lotus Notes).

It is not possible to give a general recommendation as to one of the two mechanisms at this point. However, it is possible to operate both mechanisms in parallel. In this case first of all the server requests authentication by means of SSL client certificate from the client. If the client does not possess a certificate or the user refuses to use the certificate, then the "User name and password" mechanism is used.

Example:

The table below shows the settings in the server document which enforce SSL authentication using client certificate ("Client Certificate" = Enabled) and/or SSL-protected authentication using username and password ("Name & Password" = Enabled). In order that no insecure connections are accepted, all connection requests are either forwarded to the SSL port ("TCP/IP port status" = Redirect to SSL) or else rejected ("TCP/IP port status" = Disable). The SSL port is configured so that no anonymous connections are accepted over an SSL connection ("Anonymous" = No).

* The options "Client Certificate" and "Name & Password" should not both be "Disabled" as otherwise no further connections will be accepted.