Messaging Server Administrator's Guide: Security and Access Control

Note: Because all Netscape servers support SSL, and the interface for enabling and configuring SSL through Netscape Console is nearly identical across all servers, several of the tasks described in this section are documented more completely in the SSL chapter of Managing Servers with Netscape Console. For those tasks, this chapter gives summary information only.

Obtaining Certificates

Whether you use SSL for encryption or for authentication, you need to obtain a server certificate for your Messaging Server. The certificate identifies your server to clients and to other servers.

Managing Internal and External Modules

A server certificate establishes the ownership and validity of a key pair, the numbers used to encrypt and decrypt messages. Your server's certificate and key pair represent your server's identity. They are stored in a certificate database that can be either internal to the server or on an external, removable hardware card (smartcard).

Likewise, the software module that manages the keys and certificates database can be either internal or external. Netscape servers support both internal and external modules that conform to the Public-Key Cryptography System (PKCS) #11 protocol.

Setting up the server for a certificate involves creating a database for the certificate and its keys and installing a PKCS #11 module. If you do not use an external hardware token, you create an internal database on your server, and you use the internal, default module that is part of Messaging Server. If you do use an external token, you connect a hardware smartcard reader and install its PKCS #11 module.

You can manage PKCS #11 modules, whether internal or external, through Netscape Console. To install a PKCS #11 module, you

connect a hardware card reader to the Messaging Server host machine and install drivers

use the PKCS #11 Management interface in Netscape Console to connect the PKCS #11 module to the installed driver

(For more complete instructions, see the chapter on SSL in Managing Servers with Netscape Console.)

Installing Hardware Encryption Accelerators. If you use SSL for encryption, you may be able to improve server performance in encrypting and decrypting messages by installing a hardware encryption accelerator. An encryption accelerator typically consists of a hardware board, installed permanently in your server machine, plus a software driver. Netscape Messaging Server supports accelerator modules that follow the PKCS #11 protocol. (They are essentially hardware tokens that do not store their own keys; they use the internal database for that.) You install an accelerator by first installing the hardware and drivers as specified by the manufacturer, and then completing the installation--as with hardware certificate tokens--by installing the PKCS #11 module.

Requesting a Server Certificate

You request a server certificate by opening your server in Netscape Console and running the Certificate Setup Wizard, accessed through the Console menu. Using the Wizard, you

generate a certificate request

send the request by email to the certificate authority (CA) that is to issue the certificate

When the email response from the CA arrives, you save it as a text file.

(For more complete instructions, see the chapter on SSL in Managing Servers with Netscape Console.)

Creating a Password File

On any Netscape server, when you use the Certificate Setup Wizard to request a certificate, the wizard creates a key pair to be stored in either the internal module's database or in an external database (on a smartcard). The wizard then prompts you for a password, which it uses to encrypt the stored key pair. Only that same password can later be used to decrypt the keys. The wizard does not retain the password nor store it anywhere.

On most Netscape servers for which SSL is enabled, the administrator is prompted at startup to supply the password required to decrypt the key pair. On Messaging Server 4.0, however, to alleviate the inconvenience of having to enter the password multiple times (it is need by at least three server processes), and to facilitate unattended server restarts, the password is read from a password file.

The password file must be named sslpassword.conf and must be in the directory installDirectory/config/. Entries in the file are individual lines with the format

moduleName:password

where moduleName is the name of the (internal or external) PKCS #11 module to be used, and password is the password that decrypts that module's key pair. The password is stored as clear (unencrypted) text.

Messaging Server 4.0 provides a default version of the password file, with the following single entry (for the internal module and default password):

Communicator Certificate DB:netscape!

If you specify anything but the default password when you install an internal certificate, you need to edit the above line of the password file to reflect the password you specified. If you install an external module, you need to add a new line to the file, containing the module name and the password you specified for it.

Important: Because the administrator is not prompted for the module password at server startup, it is especially important that you ensure proper administrator access control to the server and proper physical security of the server host machine and server backups.

Installing the Certificate

Installing is a separate process from requesting. Once the email response to your request for a certificate has arrived and been saved as a text file, run the Certificate Setup Wizard once more to install the file as a certificate. When you run the wizard, you

specify that you are installing a certificate that you have already obtained

paste the text of your certificate into a field when prompted to do so

(For more complete instructions, see the chapter on SSL in Managing Servers with Netscape Console.)

Note: This is also the process you follow to install a CA certificate (described next), which your server uses to determine whether to trust the certificates presented by clients.

Installing Certificates of Trusted CAs

You also use the Certificate Setup Wizard to install the certificates of certificate authorities. A CA certificate validates the identity of the CA itself. Your server uses these CA certificates in the process of authenticating clients and other servers.

If, for example, you set up your enterprise for certificate-based client authentication in addition to password-based authentication (see Setting Up Certificate-Based Login), you need to install the CA certificates of all CAs that are trusted to issue the certificates that your clients may present. These CAs may be internal to your organization or they may be external, representing commercial or governmental authorities or other enterprises. (See Introduction to Cryptography for more details on the use of CA certificates for authentication.)

When installed, Messaging Server initially contains CA certificates for several commercial CAs. If you need to add other commercial CAs or if your enterprise is developing its own CA for internal use (using Netscape Certificate Server), you need to obtain and install additional CA certificates.

Note: The CA certificates automatically provided with Messaging Server are not initially marked as trusted. You need to edit the trust settings before your server can trust client certificates issued by these CAs. See Managing Certificates and Trusted CAs for instructions.

To request and install a new CA certificate, you

contact the certificate authority (possibly through the Web or by email) and request a CA certificate

save the received the text of the certificate as a text file

Use the Certificate Setup Wizard, as described in the previous section, to install the certificate.

(For more complete instructions, see the chapter on SSL in Managing Servers with Netscape Console.)

Managing Certificates and Trusted CAs

Your server can have more than one server certificate with which it identifies itself. It can also have any number of certificates of trusted CAs that it uses for authentication of clients.

You can view, edit the trust settings of, or delete any of the certificates installed in your Messaging Server by opening your server in Netscape Console and choosing the Certificate Management Command in the Console menu. For instructions, see the chapter on SSL in Managing Servers with Netscape Console.

Enabling SSL

You can use Netscape Console to enable SSL and to select the set of encryption ciphers that Messaging Server can use in its encrypted communications with clients.

About Ciphers

A cipher is the algorithm used to encrypt and decrypt data in the encryption process. Some ciphers are stronger than others, meaning that a message they have scrambled is more difficult for an unauthorized person to unscramble.

A cipher operates on data by applying a key--a long number--to the data. Generally, the longer the key the cipher uses during encryption, the harder it is to decrypt the data without the proper decryption key.

When a client initiates an SSL connection with a Messaging Server, the client lets the server know what ciphers and key lengths it prefers to use for encryption. In any encrypted communication, both parties must use the same ciphers. Because there are a number of cipher-and-key combinations in common use, a server should be flexible in its support for encryption. Netscape Messaging Server 4.0 can support up to 6 combinations of cipher and key length.

Table 6.1 lists the ciphers that Messaging Server supports for use with SSL 3.0. The table summarizes information that is available in more detail in Introduction to SSL; please consult that document before making final decisions on what ciphers to support

Table 6.1 SSL ciphers for Messaging Server


Cipher	Description
RC4 with 128-bit encryption and MD5 message authentication	The fastest encryption cipher (by RSA) and a very high-strength combination of cipher and encryption key. Suitable only for domestic North American (non-export) use.
Triple DES with 168-bit encryption and SHA message authentication	A slower encryption cipher (a U.S. government-standard) but the highest-strength combination of cipher and encryption key. Suitable only for domestic North American (non-export) use.
DES with 56-bit encryption and SHA message authentication	A slower encryption cipher (a U.S. government-standard) and a moderate-strength combination of cipher and encryption key. Suitable only for domestic North American (non-export) use.
RC4 with 40-bit encryption and MD5 message authentication	The fastest encryption cipher (by RSA) and a lower-strength combination of cipher and encryption key. Suitable for international use.
RC2 with 40-bit encryption and MD5 message authentication	A slower encryption cipher (by RSA) and a lower-strength combination of cipher and encryption key. Suitable for international use.
No encryption, only MD5 message authentication	No encryption; use of a message digest for authentication alone.

Unless you have a compelling reason for not using a specific cipher, you should support them all. However, note that export laws restrict the use of certain encryption ciphers in certain countries. Basically, key lengths of greater than 40 bits can be used only in the United States and Canada. See Export Restrictions on International Sales on the Netscape DevEdge Web site for details. In general, Messaging Server cannot use the higher-strength encryption for any communication with international versions of client software.

Turning On SSL and Selecting Ciphers

If your Messaging Server has an installed server certificate, SSL is enabled as long as one or more encryption ciphers is selected. (Most are on by default.) Thus you can effectively enable or disable SSL communications by selecting or deselecting encryption ciphers. Follow these steps:

In Netscape Console, open the Messaging Server whose cipher settings you want to modify.

Click the Configuration tab in the left pane.

Select the Services folder.

Select the Encryption tab in the right pane. The Encryption Configuration form opens.

Click the boxes to select the encryption cipher or ciphers that you want your server to support. To disable SSL completely, deselect all ciphers.

See Encryption Configuration Tab for a complete description of the contents of that form.

Setting Up Certificate-Based Login

In addition to password-based authentication, Netscape servers support authentication of users through examination of their digital certificates. In certificate-based authentication, the client establishes an SSL session with the server and submits the user's certificate to the server. The server then evaluates whether the submitted certificate is genuine. If the certificate is validated, the user is considered authenticated.

To set up your Messaging Server for certificate-based login:

Obtain a server certificate for your server. (See Obtaining Certificates for details.)

Run the Certificate Setup Wizard to install the certificates of any trusted certificate authorities that will issue certificates to the users your server will authenticate. (See Installing Certificates of Trusted CAs for details.)

Note that, as long as there is at least one trusted CA in the server's database, the server requests a client certificate from each connecting client.

Turn on SSL. (See Enabling SSL for details.)

(Optional) Edit your server's certmap.conf file so that the server appropriately searches the LDAP user directory based on information in the submitted certificates.

Editing the certmap.conf file is not necessary if the email address in your users' certificates matches the email address in your users' directory entries, and if you do not need to optimize searches or validate the submitted certificate against a certificate in the user entry.

For details of the format of certmap.conf and the changes you can make, see the SSL chapter of Managing Servers with Netscape Console.

Once you have taken these steps, when a client establishes an SSL session so that the user can log in to IMAP, the Messaging Server requests the user's certificate from the client. If the certificate submitted by the client has been issued by a CA that the server has established as trusted, and if the identity in the certificate matches an entry in the user directory, the user is authenticated and access is granted (depending on access-control rules governing that user).

There is no need to disallow password-based login (see Password-Based Login) to enable certificate-based login. If password-based login is allowed (which is the default state), and if you have performed the tasks described in this section, both password-based and certificate-based login are supported. In that case, if the client establishes an SSL session and supplies a certificate, certificate-based login is used. If the client does not use SSL or does not supply a certificate, the server requests a password.

For more details on setting up your entire installation of Netscape servers and clients to use certificate-based authentication, see Single Sign-On Deployment Guide.

Configuring Administrator Access to Messaging Server

This section describes how to control the ways in which server administrators can gain access to Messaging Server. Administrative access to a given Messaging Server and to specific Messaging Server tasks occurs within the context of delegated administration. Delegated administration is a feature of all Netscape servers; it refers to the capability of an administrator to provide other administrators with selective access to individual servers and server features. For an overview of delegated administration, see the chapter on delegating server administration in Managing Servers with Netscape Console.

Note: Most tasks described in this section are common to all Netscape servers, and are therefore described fully only in the chapter on delegating server administration in Managing Servers with Netscape Console. This chapter briefly summarizes the tasks.

Hierarchy of Delegated Administration

When you install the first Netscape server on your network, the installation program automatically creates a group in the LDAP user directory called the Configuration Administrators group. By default, the members of the Configuration Administrators group have unrestricted access to all hosts and servers on your network.

The Configuration Administrators group is at the top of an access hierarchy, such as the following, that you can create to implement delegated administration for Messaging Server:

Configuration administrator. The "super user" for the network of Netscape servers. Has complete access to all resources.

Domain administrator. The configuration administrator typically creates one or more other groups, each with more restricted access. For example the configuration administrator might create a Domain Administrators group and give it access to all server for a specific administrative domain in the network. (An administrative domain is the set of hosts and servers on the network that share the same user directory for looking up account information.)

Server administrator. A domain administrator might create groups to administer each type of server. For example, a Messaging Administrators group might be created to administer all Messaging Servers in an administrative domain or across the whole network. Members of that group have access to all Messaging Servers (but no other servers) in that administrative domain.

Task administrator. Finally, any of the above administrators might create a group, or designate an individual user, with restricted access to a single Messaging Server or a set of Messaging Servers. Such a task administrator is permitted to perform only specific, limited server tasks (such as starting or stopping the server only, or accessing logs of a given service).

Netscape Console provides convenient interfaces that allow an administrator to

grant a group or an individual access to a specific Messaging Server, as described in Providing Access to the Server as a Whole (next)

restrict that access to specific tasks on a specific Messaging Server, as described in Restricting Access to Specific Tasks

Providing Access to the Server as a Whole

To give a user or group permission to access a given instance of Messaging Server, you

select that server in the Console window, and choose Set Access Permissions in the Console menu

add or edit the list of users and groups with access to the server

(For more complete instructions, see the chapter on delegating server administration in Managing Servers with Netscape Console):

Once you have set up the list of individuals and groups that have access to the particular Messaging Server, you can then use ACIs, as described next, to delegate specific server tasks to specific people or groups on that list.

Restricting Access to Specific Tasks

An administrator typically connects to a server to perform one or more administrative tasks. Common administrative tasks are listed in the Messaging Server Tasks form in Netscape Console (see Figure 1.12).

By default, access to a particular Messaging Server means access to all of its tasks. However, each task in the Task form can have an attached set of access-control instructions (ACIs). The server consults those ACIs before giving a connected user (who must already be a user with access permissions to the server as a whole) access to any of the tasks. In fact, the server displays in the Tasks form only those tasks to which the user has permission.

If you have access to a Messaging Server, you can create or edit ACIs on any of the tasks (that is, on any of the tasks to which you have access), and thus restrict the access that other users or groups can have to them.

To restrict the task access that a connected user or group can have, you

log in to the Netscape Console as an administrator with access to the Messaging Server you want to provide restricted access to

open the server and select a task in the server's Tasks form

choose Set Access Permissions from the Edit menu, and add or edit the list of access rules to give a user or group the kind of access you want them to have.

Repeat the process for other tasks, as appropriate

(For more complete instructions, see the chapter on delegating server administration in Managing Servers with Netscape Console):

For example, suppose you want to create a group of administrators responsible for log analysis, and you also have an individual (Miranda) who is responsible for filtering out unsolicited bulk email (UBE). You can

create a group called Logging Admins and add the appropriate people to it

use Set Access Permissions for the Netscape Console Configuration window to give both Logging Admins and Miranda access to the Messaging Server

use Set Access Permissions for the Messaging Server Tasks form to place ACIs on the various tasks, making sure that the Logging Admin group sees (and thus has access to) only the logging-related tasks, and that Miranda sees only the UBE filter-configuration task

ACIs and how to create them are described more fully in the chapter on delegating server administration in Managing Servers with Netscape Console.

Configuring Client Access to TCP Services

Messaging Server supports sophisticated access control on a service-by-service basis for its TCP-based services (IMAP, POP, and SMTP), so that you can exercise far-ranging and fine-grained control over which users can gain access to your server.

If you are managing messaging services for a large enterprise or an Internet service provider, these capabilities can help you to exclude spammers and DNS spoofers from your system and improve the general security of your network. For control of spam mail (unsolicited bulk email) specifically, see also Chapter 8, Filtering Unsolicited Bulk Email.

Note: If controlling user access is not an important issue for your enterprise, you do not have to create any of the filters described in this section. If minimal access control is all you need, see the section Mostly Allowing for instructions on setting it up.

How Client Access Filters Work

The Messaging Server access-control facility for TCP clients is an implementation of the TCP wrapper concept. A TCP wrapper is a program that listens at the same port as the TCP daemon it serves; it uses access filters to verify client identity, and it gives the client access to the daemon if the client passes the filtering process. The design of the Messaging Server TCP wrapper is based on the Unix Tcpd access-control facility (created by Wietse Venema) and the identd service (described in Internet draft RFC 1413).

As part of its processing, the Messaging Server TCP client access-control system performs (when necessary) the following analyses of the socket end-point addresses:

Reverse DNS lookups of both end points (to perform name-based access control)

Forward DNS lookups of both end points (to fight DNS spoofing)

Identd callback (to check that the user on the client end is known to the client host)

The system compares this information against access-control statements called filters to decide whether to grant or deny access. For each service, separate sets of Allow filters and Deny filters control access. Allow filters explicitly grant access; Deny filters explicitly forbid access.

When a client requests access to a service, the access-control system compares the client's address or name information to each of that service's filters--in order--using these criteria:

The search stops at the first match. Because Allow filters are processed before Deny filters, Allow filters take precedence.

Access is granted if the client information matches an Allow filter for that service.

Access is denied if the client information matches a Deny filter for that service.

If no match with any Allow or Deny filter occurs, access is granted--except in the case where there are Allow filters but no Deny filters, in which case lack of a match means that access is denied.

The filter syntax described here is flexible enough that you should be able to implement many different kinds of access-control policies in a simple and straightforward manner. You can use both Allow filters and Deny filters in any combination, even though you can probably implement most policies by using almost exclusively Allows or almost exclusively Denies.

The following sections describe filter syntax in detail and give usage examples.The section Creating Access Filters with Netscape Console gives the procedure for creating access filters.

Filter Syntax

Filter statements contain both server information and client information. The server information can include the name of the service, names of hosts, and addresses of hosts. The client information can include host names, host addresses, and user names. Both the server and client information can include wildcard names or patterns.

The very simplest form of a filter is

service: hostSpec

where service is the name of the service (such as smtp, pop, or imap) and hostSpec is the host name, IP address, or wildcard name or pattern that represents the client requesting access. When a filter is processed, if the client seeking access matches hostSpec, access is either allowed or denied (depending on which type of filter this is) to the service specified by service. Here are two examples:

imap: roberts.newyork.airius.com

pop: ALL

If these are Allow filters, the first one grants the host roberts.newyork.airius.com access to the IMAP service, and the second one grants all clients access to the POP service. If they are Deny filters, they deny those clients access to those services. (See Wildcard Names for descriptions of wildcard names such as ALL.)

Either the server or the client information in a filter can be somewhat more complex than this, in which case the filter has the more general form of

serviceSpec: clientSpec

where serviceSpec can be either service or service@hostSpec, and clientSpec can be either hostSpec or user@hostSpec. user is the user name (or a wildcard name) associated with the client host seeking access. Here are two examples:

smtp@mailServer1.airius.com: ALL

imap: srashad@xyz.europe.airius.com

If these are Deny filters, the first filter denies all clients access to the SMTP service on the host mailServer1.airius.com. The second filter denies the user srashad at the host xyz.europe.airius.com access to the IMAP service. (See Server-Host Specification and Client User-Name Specification for more information on when to use these expanded server and client specifications.)

Finally, at its most general, a filter has the form

serviceList: clientList

where serviceList consists of one or more serviceSpec entries, and clientList consists of one or more clientSpec entries. Individual entries within serviceList and clientList are separated by blanks and/or commas.

In this case, when a filter is processed, if the client seeking access matches any of the clientSpec entries in clientList, then access is either allowed or denied (depending on which type of filter this is) to all the services specified in serviceList. Here is an example:

pop, imap: .europe.airius.com .newyork.airius.com

If this is an Allow filter, it grants access to both POP and IMAP services to all clients in either of the domains europe.airius.com and newyork.airius.com. (See Wildcard Patterns for information on using a leading dot or other pattern to specify domains or subnets.)

Wildcard Names

You can use the following wildcard names to represent service names, host names or addresses, or user names:


Wildcard Name	Explanation
ALL	The universal wildcard. Matches all names.
LOCAL	Matches any local host (one whose name does not contain a dot character). However, if your installation uses only canonical names, even local host names will contain dots and thus will not match this wildcard.
UNKNOWN	Matches any user whose name is unknown, or any host whose name or address is unknown. Use this wildcard name carefully: Host names may be unavailable due to temporary DNS server problems--in which case all filters that use UNKNOWN will match all client hosts. A network address is unavailable when the software cannot identify the type of network it is communicating with--in which case all filters that use UNKNOWN will match all client hosts on that network.
KNOWN	Matches any user whose name is known, or any host whose name and address are known. Use this wildcard name carefully: Host names may be unavailable due to temporary DNS server problems--in which case all filters that use KNOWN will fail for all client hosts. A network address is unavailable when the software cannot identify the type of network it is communicating with--in which case all filters that use KNOWN will fail for all client hosts on that network.
DNSSPOOFER	Matches any host whose DNS name does not match its own IP address.