Security

---

Security is a primary concern for any application used to manage sensitive, personal information. A number of options are available to an administrator seeking to enhance or customize the security of a calendar server installation. In addition to increasing the security of the operating environment and implementing good maintenance and monitoring practices, calendar server administrators have access to a configurable, extensible Authentication, Compression and Encryption (ACE) framework.

This appendix describes the structure and configuration of the authentication, compression and encryption methods. Additional security considerations for installations using a directory server are detailed, as well as a number of other measures that may be employed to further protect calendar data.

• ACE framework
• Directory server security
• Other security considerations

ACE framework

The ACE framework was developed to allow administrators to ensure the security and integrity of all data passing between calendar servers, and between server and client. CorporateTime desktop clients 5.0 and above, Web clients 2.0 and above, or CorporateTime Outlook Connector are required to take full advantage of this functionality.

Data passes between the server and clients, and between multiple servers if nodes are distributed across more than one host. If an external directory is used, data also passes between the calendar server and the LDAP directory server. The ACE framework applies only to communication between the calendar server(s) and clients. See "Directory server security" for a separate discussion of the security options for data passing between calendar servers and their supporting directory servers.

For earlier versions of the calendar server, or for installations where ACE is not enabled, the basic level of security protects unauthorized access by requiring all users and all other calendar servers to authenticate before connecting. In an installation connected a directory server, the calendar server authenticates users with the directory server. The built in authentication method, cs-basic, is faster and slightly less secure than other authentication methods.

Secure connections may involve the use of compression (to reduce the network bandwidth required for communications) and/or encryption (to enhance the security of network communications). Both compression and encryption increase the amount of CPU time required to prepare the communication for transmission. The impact on performance varies with the methods. In general, the better the compression or the more secure the encryption, the greater the impact on performance.

Secure connections to clients and other calendar servers

Secure connections to calendar clients and other calendar servers are controlled by a configurable set of authentication, compression and encryption methods. These methods are determined at the time the connection is requested. The ACE methods are both configurable and extensible. See "Configuration" for the relevant configuration parameters, and "Extending the ACE framework" for details on extending the available set of methods.

Secure connections to clients

NOTE

Only CorporateTime desktop clients 5.0 and higher, Web clients 2.0 and higher and CorporateTime Outlook Connector support the ACE framework. All other clients authenticate using the built-in authentication method (cs-basic) and do not use any compression or encryption.

The calendar server negotiates with a client as follows.

1. The client starts up and connects to the server.
2. The client queries the server for the supported and default authentication, compression, and encryption methods.
3. The server returns a list of the supported and default authentication, compression and encryption methods.
4. If the client cannot support one of the default methods, the server and client negotiate using the list of supported methods sent to the client in step 3 to agree on a method that both support. Note that one of the supported methods for both compression and encryption is "none", making both compression and encryption optional.
5. The server authenticates the user using the negotiated authentication method.
6. The client and server communicate using the agreed upon methods for the duration of the user session.

NOTE

If the client and server cannot agree on authentication, compression and encryption methods, the negotiation fails and the server does not accept requests from the client.

Secure connections to another calendar server

The server negotiates with another calendar server as follows.

1. Server A receives a request from Server B.
2. Server A sends Server B a list of the supported and default authentication, compression, and encryption methods.
3. If Server B cannot support one of the default methods, Server A and Server B negotiate using the lists of supported methods sent in step 2 to agree on a method that both support. Note that one of the supported methods for both compression and encryption is "none", making both compression and encryption optional.
4. Server A authenticates Server B using the negotiated authentication method.
5. Servers A and B communicate using the agreed upon methods for the duration of the connection.

   Recall that communication between two calendar servers is through the uniengd. In this case, the uniengd on Server B asks the unisncd on Server B for a connection to a uniengd on Server A. The methods are in effect until the requesting uniengd on Server B returns the connection to the unisncd.

NOTE

If the two servers cannot agree on authentication, compression and encryption methods, the negotiation fails and Server A does not accept requests from Server B.

Configuration

To enable the ACE framework and ensure secure server-to-client or server-to-server connections in a node network, set the [ACE] frameworkenable parameter in the unison.ini file to TRUE.

The following table lists the parameters used to configure the authentication, compression and encryption methods used for communication within a calendar network (server to client, server to server). See "Extending the ACE framework" below for information on extending the sets of supported methods. Consult the appropriate page in Reference Appendix B, "Server Parameters," for details on these parameters.

Table D.1 · ACE configuration parameters

Section	Parameter	Description	Page
[ACE]	frameworkenable	Enable the ACE framework	105
[AUTHENTICATION]	supported	Supported authentication methods for clients	107
	default	Default authentication method for clients	108
[COMPRESSION]	supported	Supported compression methods	109
	default	Default compression method for clients	110
	servicedefault	Default compression method for other servers	110
[ENCRYPTION]	supported	Supported encryption methods	111
	needsauthenticate	Encryption methods requiring prior authentication	111
	default	Default encryption method for clients	112
	servicedefault	Default encryption method for other servers	112

Extending the ACE framework

The ACE framework provides an interface to an extensible set of authentication, compression, and encryption plug-ins. This section describes the use of these plug-ins, and details the mechanism for extending the set of plug-ins available in the server.

Figure D.1 · ACE framework architecture

Plug-ins

Each plug-in is a shared library under UNIX, or a DLL under NT. The name of the plug-in contains a substring that indicates the type of the plug-in, as shown in the following table.

Substring	Type of plug-in	Examples
aut_	Authentication	aut_cs-standard.dll (NT) libaut_cs-standard.sl (HP-UX) libaut_cs-standard.so (SunOS) libaut_sasl.so (SunOS)
cmp_	Compression	cmp_cs-simple.dll (NT) libcmp_cs-simple.sl (HP-UX) libcmp_cs-simple.so (SunOS)
enc_	Encryption	enc_cs-acipher1.dll (NT) libenc_cs-acipher1.sl (HP-UX) libenc_cs-acipher1.so (SunOS)

NOTE

The cs-basic authentication plug-in is not a true plug-in in that it is not a shared library. It pre-dates the ACE framework as the authentication method built into the server.

Extending the set of plug-ins

To extend the set of plug-ins available through the ACE framework, first install the plug-in on your system, and then integrate it into the server. The installation of plug-ins is the responsibility of the system administrator. Consult the appropriate documentation for details. To integrate the plug-in into the calendar server, add the appropriate keywords to one or more places in the unison.ini file.

For all methods except those that support sub-mechanisms, derive the keyword from the name of the plug-in in the following manner. Remove the substring "aut_", "cmp_", or "enc_" and all characters that precede it. Remove the filename extension and the period that precedes it. The remaining string is the keyword to add to the unison.ini file.

Plug-in Name	Keyword
aut_cs-standard.dll libcmp_cs-simple.sl libenc_cs-acipher1.so	cs-standard cs-simple cs-acipher1

In the case of plug-ins which support sub-mechanisms, the keyword has the format <plug-in_name>:<sub-mechanism_name>. Derive <plug-in_name> as described above. Consult the plug-in documentation to determine <sub-mechanism_name>. For example:

Plug-in Name	Keyword
libaut_sasl.so	sasl:GSSAPI

Once you have determined the keyword, add it to the appropriate list of supported methods in the unison.ini file. Add authentication methods to the [AUTHENTICATION] supported parameter, compression methods to the [COMPRESSION] supported parameter, and encryption methods to the [ENCRYPTION] supported parameter. If you want the new method to be the default, also set the appropriate default and/or servicedefault parameters. For more details on these parameters, please consult Reference Appendix B, "Server Parameters."

SASL

The Simple Authentication and Security Layer (SASL) plug-in provides both authentication and encryption methods.

To enable SASL authentication, follow the steps described above. To also enable SASL encryption, add the method sasl:encryption to the [ENCRYPTION] supported list. You must use SASL authentication in order to enable SASL encryption. For additional SASL configuration options, consult the unison.ini [ACE-PLUGINS] parameters described in Reference Appendix B.

NOTE

To enable SASL encryption, you must install libsasl.dll on the client side, available through Carnegie Mellon University web site at:

http://asg.web.cmu.edu/sasl/sasl-library.html

Supported SASL submechanisms include KERBEROS_V4, GSSAPI (Kerberos 5), and CRAM-MD5. Other SASL submechanisms not based on username/password credentials may or may not also perform correctly.

NOTE

It is recommended that you do not enable both sasl:KERBEROS_V4 and sasl:GSSAPI at the same time.

Using Kerberos

If you choose to use Kerberos with CorporateTime Server, you must assign your calendar server a service principal in your Kerberos database. The ACE plug-ins that accept Kerberos require the following service principals:

plug-in:submechanism	Principal name	Principal type
sasl:KERBEROS_V4	uniengd	host name without domain
sasl:GSSAPI	uniengd	fully qualified host name with domain
gssapi:kerberos5	uniengd	fully qualified host name with domain

After creating the service principal, you must export it to a keytab file and copy that file to the calendar server host. Specify the file name and path in the value of the unison.ini [ACE_PLUGINS] <plug-in>_<submechanism>_srvtab parameter. For example,

[ACE_PLUGINS]

sasl_GSSAPI_srvtab = /etc/krb.4.keytab

For additional Kerberos configuration options, consult the unison.ini [ACE-PLUGINS] parameters described in Reference Appendix B.

Web authentication plug-in

The Web authentication plug-in configures the calendar server to trust Web server authentication methods, allowing users to view their calendars without having to sign in explicitly to the calendar server.

This plug-in is supported by Oracle Web clients version 3.0 or greater and Oracle calendar servers of version 5.2 and 5.3. Future versions of the calendar server will feature enhanced Web authentication capabilities through an updated version of this plug-in. The aut_web module must be configured correctly on both the client side and server side.

Please note that the libraries included in this package are for use with 5.2 and 5.3 versions of the calendar server only. They are not the same as the libraries that are installed with your Web client, and they should not be used by either the Web client or any versions of the calendar server 6.0 and above.

How does the Web authentication plug-in work?

1. The Web authentication plug-in identifies itself to the calendar server when the Web client FastCGI is started. This is done through comparing the values of two parameters, one stored in the calendar Web client configuration file (webcal.ini), and one stored in the calendar server configuration file (unison.ini). If the values of these parameters are the same, the calendar server will trust the Web authentication plug-in as a proxy authenticator.
2. When a user is authenticated with the Web server and attempts to access a FastCGI application, the server stores some of that user's attributes in environment variables.
3. When that user attempts to view his or her calendar, the Web calendar client application calls the Web authentication plug-in.
4. The Web authentication plug-in then retrieves the user information stored in the Web server environment variables, and uses that information to identify the current user to the calendar server. It passes the value of a specified environment variable to the calendar server, and indicates what user attribute in the calendar database that environment variable represents. Currently, the only attribute supported is the user's UID.
5. The calendar server looks for a user whose UID matches the value submitted. If it finds a match, the user is signed directly in to their Web calendar.

Configuring your calendar server

1. Edit the users/unison/misc/unison.ini file.
2. Ensure that the [ACE] frameworkenable parameter is set to TRUE.
3. Add the Web authentication plug-in, represented by the string web:CAL, to the list of supported authentication methods given in the [AUTHENTICATION] supported parameter. For example:

   [AUTHENTICATION]

   supported = {cs-standard, web:CAL}

4. Create a new section called [ACE_PLUGINS_SERVER] and a new parameter called web_CAL_sharedkey to specify the shared key to be used by the Web authentication plug-in. The value of this parameter should be a simple plain-text password. For example:

   [ACE_PLUGINS_SERVER]

   web_CAL_sharedkey = mypassword

Configuring your Web calendar client

1. Edit the webcal.ini file.
2. Enable the Web authentication plug-in by changing the value of the [ACE] authentication parameter to web:CAL. Set this parameter as follows:

   [ACE]

   authentication = web:CAL

3. Create a new section called [ACE_PLUGINS_CLIENT] and a new parameter called web_CAL_sharedkey to specify the shared key to be used by the Web authentication plug-in. The value of this parameter must match the value you set for the calendar server unison.ini [ACE_PLUGINS_SERVER] web_CAL_sharedkey parameter. For example:

   [ACE_PLUGINS_CLIENT]

   web_CAL_sharedkey = mypassword

4. Add a new parameter, [ACE_PLUGINS_CLIENT] web_attribute_type, to specify the calendar user attribute that will be used to match the value of the Web server environment variable. Currently, this parameter may take either of two values:
   • userid, which forces the calendar server to identify users by comparing the value of the Web server environment variable with calendar server UIDs, or
   • custom, which processes the value of the Web server environment variable through a separate script before comparing it with calendar server UIDs.

     For example:

     web_attribute_type = userid

     If you choose to use the custom option for the [ACE_PLUGINS_CLIENT] web_attribute_type parameter, then you must add another parameter, [ACE_PLUGINS_CLIENT] web_custom_script, to specify the script to be used. For example:

     web_custom_script = /usr/local/apache/ctw-bin/lexacal/custom.sh

     Sample script: This sample shell script (UNIX only) takes e-mail addresses stored in the Web server environment variable SSL_CLIENT_S_DN_Email, strips off the @ character and all characters following, and returns the remaining characters to be matched against users' calendar server UIDs:

     #!/bin/sh

     
     

     echo userid

     echo $SSL_CLIENT_S_DN_Email | sed s/\@.*//g

     To use this script, save it as an executable on your Web server, and supply the path and file name using the web_custom_script parameter. Use this script as a template for designing your own custom scripts. Output must be two lines: the attribute type on the first line and the value on the second.

NOTE

If more than one Web client application is running on the same UNIX machine using the custom option, each Web client must run under a different user name.

5. Add a new parameter, [ACE_PLUGINS_CLIENT] web_attribute_name, to specify the Web server environment variable to use for identifying calendar users. For example:

   web_attribute_name = SSL_CLIENT_S_DN_UID

   Any environment variable may be used. When the web_attribute_type parameter is set to userid, the value of the environment variable specified by the web_attribute_name parameter must be equivalent to the calendar server UID. When the web_attribute_type parameter is set to custom, the specified script must convert the value of the environment variable specified by the web_attribute_name parameter into a valid calendar server UID.

6. Specify the default page to load if the calendar server is unable to match the authenticated user. Set the [href] login_fail_url parameter to the desired path and file name, enclosed in quotes. For example:

   [href]

   login_fail_url = "<filename>"

NOTE

By default, errors and warnings will be logged to a file in the same directory as the Web calendar client application. To specify another directory for the log file, use the [ACE_PLUGINS_CLIENT] web_logfile parameter.

Directory server security

Secure connections to an LDAP directory server use Secure Socket Layer (SSL) encryption to protect the data that flows between the calendar server and the LDAP directory server. In general, these connections pose less of a security risk than connections between calendar servers and clients because both the calendar server host and the directory server host are normally on a restricted hub.

Enabling secure connections to an LDAP directory server

For complete instructions on setting up your calendar server to communicate with your directory server using SSL, see Chapter 3, "Using an external LDAP directory."

Other security considerations

The following safeguards can be used to enhance the security of calendar data.

Dedicated Server

We recommend that the calendar server, if financial resources permit, be placed on a dedicated computer. Additionally, turn off any TCP and UDP services on the host which are not critical to the calendar server (e.g., ftp, NFS server and client, X server, etc.). There should be only two accounts configured on the system: unison and root (UNIX) or administrator (NT).

Password Management

The following are policy/procedure recommendations on the operations and maintenance of passwords:

• When users are initially assigned a password, they should be required to change this password to one of their own choosing.
• Manual policies should enforce the following password rules:
  • Passwords should never be empty (or blank). This is especially important for the SYSOP or node administrator password.
  • Passwords should never be words, names, or personal information which would be easy for others to guess.
  • Passwords should be at least 8 characters long, and contain a combination of letters and numbers.
  • Avoid using the same password to access the calendar server and other mission-critical systems (although this may not be possible if these applications all use the same directory server).

Trust Management

Even if the server is dedicated to the calendaring application, there are still additional security safeguards to consider.

If you have security servers within your organization, consider sending audit trail information from the calendar server to your central security server. Turn on auditing for the server and conduct spot audits of the commands issued by the unison user. The server protects a great deal of aggregate data; ensure that your backups are protected from theft. Consider separate ownership of the root/administrator (auditing account) and the unison (server management) accounts. This would allow root/administrator to detect potential abuses by the unison owner.

Networking

It is more secure to run mission-critical applications within firewall-protected intranets. Make sure that the dial-up connections to your intranet are protected. This can be improved by using one-time password technology (e.g. SecurID). As with many TCP/IP protocols, promiscuous listening (where the attacker monitors network traffic) is a threat in any broadcast network. A number of steps can be performed to reduce the risk of this threat:

• Physically protect hubs and routers. Use switched hubs when possible, especially on the server itself. Some hubs will block unauthorized, or unregistered MAC (or ethernet addresses) on the LAN.
• Consider router filtering between untrusted internal networks.
• Use commercial firewalls to allow more complex TCP/IP filtering rules.

Auditing

The server generates a number of useful audit trails. It is important to become familiar with these audit trails, and to check them regularly. Many commands will create log files on error conditions. Routinely check for the existence of new log files, and review their contents. Monitor the /users/unison/log/act.log for login attempt abuses. You can detect login attempt abuses from the originating IP addresses. After the application is initially installed, record the file dates, file sizes, and checksums of all the binaries (the unicksum utility generates a checksum for a file). Periodically check that none of the binaries have been edited by comparing the current file dates, file sizes, and checksums with those recorded. Review <temp> directories for any suspicious files as they can be used as work areas.

Backup and Recovery

Calendar data is very important and should be backed up regularly. See Chapter 10, "Back up and restore," for more information.

Application Security

The server supports a very rich set of user-controlled access privileges (or rights). It is important to train end-users on how these capabilities can be managed, so that the users' information is protected from unauthorized access.

Try to limit assigning designate rights. You should only give designate rights to trusted individuals.

The default designate rights should be no designate rights. Set the viewing rights to no privileges, and add privileges as needed.

There are a number of overall limits, set by the server administrator, that can be set for all users.

Disabling attachments ([LIMITS] allowattachments) can prevent users from propagating proprietary information improperly. Setting maximum attachment size ([LIMITS] maxattachmentsize) can help prevent denial of service errors caused by very large files that cause a server to run out of disk space.

Calendar Administrator

If you use the Calendar Administrator, it is recommended that you implement Secure Sockets Layer (SSL) protection for your site. Consult the Netscape SSL documentation for details.

Copyright information