Chapter 22 Planning Instant Messaging Security

This chapter describes how to plan for and protect the various components of your Instant Messaging deployment.

This chapter contains the following sections:

• Protecting Instant Messaging Components in Your Deployment

• Planning Instant Messaging User Authentication

• Planning Instant Message Privacy, Security, and Site Policies

Protecting Instant Messaging Components in Your Deployment

This section describes how to secure components in your Instant Messaging deployment.

Overview of Instant Messaging Security

Instant Messaging supports the following levels of security:

• No Security. Communication is all plain text from client through the multiplexor to the server.

• Legacy SSL. Secure communication between client and multiplexor, and plain text between multiplexor and server. (This is only relevant if you are using the multiplexor).

• startTLS. End-to-end secure communication between client and server. If you enable the multiplexor, it does not process any data but instead passes it on to the server.

The startTLS option enables end-to-end encryption (the communication between client-multiplexor-server is all in encryption form), while legacy SSL enables encryption between the Instant Messenger client up to the multiplexor: the communication between multiplexor and server is in plain text (though in a proprietary protocol). Use startTLS if you require a higher level of security. If you use startTLS, you do not need an alternate means of securing the multiplexor-to-server communication (it will be secure).

Protecting Instant Messaging Server and Multiplexor

Instant Messaging supports TLS (Transport Layer Security) and legacy SSL (Secure Sockets Layer) for secure communications. Instant Messaging uses a startTLS extension to the Transport Layer Security (TLS) 1.0 protocol for client-to-server and server-to-server encrypted communications and for certificate-based authentication between servers. In addition, Instant Messaging supports a legacy implementation of the SSL protocol (version 3.0) for encrypted communications between the Instant Messenger client and the multiplexor.

When planning for SSL for Instant Messaging, keep in mind the following:

• You can secure the Instant Messaging deployment by enabling SSL on the web container port (either Web Server or Application Server) and accessing Instant Messaging functionality by using the XMPP/HTTP Gateway (httpbind). You can also enable SSL at the mutliplexor and the Instant Messaging client can access Instant Messaging functionality directly through the mutliplexor.

• The Instant Messenger client uses only legacy SSL if it is enabled at the multiplexor. In this case, the Instant Messenger client does use startTLS of the server.

• Instant Messaging does not support end-to-end encryption using legacy SSL, so the communications between the Instant Messaging server and multiplexor is in the clear if the Instant Messaging server and multiplexor are deployed on multiple nodes and SSL is enabled at the multiplexor. If you want end-to-end encryption, you must use startTLS.

• Set the proper file and directory permissions for Instant Messaging configuration files (iim.conf and httpbind.conf in the /etc/opt/SUNWiim/default/config directory). [Instant Messaging runs as the user specified in the iim.conf file. This user needs read access to the file. If you use httpbind, the user that runs the web container should be able to access the Instant Messaging directory path and configuration file. Typically , if the deployment of Instant Messaging includes Access Manager or Portal Server, the default user is root. ] When you create additional Instant Messaging server/multiplexor instances manually, you need to also ensure that the file and directory permissions are correct. The default installation sets the file/directory permissions. The default instance directory (/var/opt/SUNWiim/default) has the following permissions:

  drwx------ 5 root other 512 Oct 16 14:24 default

• Take care when enable Instant Messaging monitoring as this exposes server statistics that could be considered security issues. The default configuration does not enable the monitoring feature. You enable this property through the iim.conf file.

• Enable debug logging only when needed, as this impacts overall system performance. Though passwords are not logged, the protocol communication between users is logged, which could be a potential security issue.

• When you enable startTLS, use a single server certificate for both client-to-server and server-to-server communication.

• The Instant Messaging server should be able to connect to Access Manager if identity integration is enabled. Similarly, Instant Messaging server needs access to the Portal Server search when deployed with Portal Server. Additionally, an Instant Messaging deployment that leverages LDAP needs proper authentication for access. Refer to each product's individual documentation to understand how to secure each component.

The Instant Messaging default installation supports only SASL Plain. If you require a higher level of security, use the Instant Messaging public Service Provider Interface. SASL Plain and jabber:iq:auth are two forms of plain text authentication. That is, in both, the password is sent in the clear (encoded perhaps, but still clear text) and so both are insecure forms of authentication. Nevertheless, this is an issue only if end-to-end encryption (through startTLS for direct socket connection, and HTTPS for httpbind) is not enabled. If end-to-end encryption is enabled, the password is not “seen” in the clear on the network.

Alternatively, if you do not want to transmit passwords in the clear (even if over an encrypted stream), use the Instant Messaging SPI for plugging in authentication mechanism's at the server side through SASLRealm. You can implement custom SASL mechanisms as implementations but you will then need an Instant Messaging client that supports this custom mechanism. The Sun Java System Instant Messaging client supports only SASL Plain, jabber:iq:auth (both insecure).

For more information, see Chapter 12, Securing Instant Messaging Using TLS and Legacy SSL, in Sun Java System Instant Messaging 7.2 Administration Guide.

Providing Instant Messaging Client Access Through a Firewall

The XMPP/HTTP Gateway (httpbind) provides Instant Messaging access to XMPP-based clients, such as HTML based clients, and clients that are behind firewalls that allow HTTP traffic only and don't permit XMPP traffic. The gateway proxies Instant Messaging traffic to the XMPP server on behalf of HTTP clients.

When planning to use the XMPP/HTTP Gateway, keep in mind the following:

• Use port 5222 at the Gateway if the Gateway is communicating to the server through a multiplexor. Also, use port server port 5269 if no multiplexor is involved. You can specify port 5222 or 5269 in the httpbind.conf file.

• The XMPP/HTTP gateway supports both startTLS and legacy SSL. If you want legacy SSL support, enable SSL on the Web Server port. However, if the XMPP/HTTP gateway configuration points to the multiplexor instead of the server, disable legacy SSL at the multiplexor. Additionally, if you want startTLS support, enable startTLS on the server and all communications will be encrypted.

• Do not expose the Instant Messaging server to direct access. In a typical deployment scenario you would locate the multiplexor in the DMZ, and open the multiplexor to server communication port (45222 usually) in the second firewall.

Protecting the Instant Messaging Archive

Instant Messaging has the capability to archive instant messages for later retrieval and searching. If you enable the email archive, you need to decide which administrators will receive email containing archived instant messages. You can configure a separate list of administrators to receive polls, news, conference, alerts, or chat sessions. You can also configure Instant Messaging to use the extended RFC 822 header. Doing so allows mail clients to filter messages based on the header content. If you do enable the Portal archive, you can decide which administrators can access the Portal archive database.

For more information, see Chapter 18, Managing Archiving for Instant Messaging, in Sun Java System Instant Messaging 7.2 Administration Guide.

Planning Instant Messaging User Authentication

User authentication enables your users to log in through their Instant Messaging clients to chat and access other features of Instant Messaging.

Instant Messaging and Passwords

User IDs and passwords are stored in your LDAP directory. Password security criteria, such as minimum length, are determined by directory policy requirements. Password security criteria is not part of Instant Messaging administration. See the Directory Server documentation to understand directory server password policies:

http://docs.sun.com/coll/1316.1

Instant Messaging and LDAP

All deployments of Instant Messaging require a directory server. In a deployment without Access Manager, the Instant Messaging server uses the directory server to perform end-user authentication and to search for end users. For various ways to secure the directory, see the Directory Server documentation.

In a deployment with Portal Server, the Instant Messaging server uses the directory used by Portal Server. When installed in an Access Manager deployment environment, the Instant Messaging server uses the directory used by the Access Manager to search for end users, and not for end-user authentication. In an Access Manager deployment, Access Manager performs the authentication.

If you use an LDAP directory to maintain your user namespace, the default configuration makes the following assumptions regarding the schema used by this directory:

• End user entries are identified by the inetOrgPerson object class.

• Group entries are identified by the groupOfUniqueNames or groupofURLs object class.

• Instant Messenger user ID attribute of an end user is provided by the uid attribute (from inetOrgPerson objectclass).

• The email address of an end user is provided by the mail attribute.

• The display name of an end user or group is provided by the cn attribute.

• The list of members of a group is provided by the uniqueMember attribute (groupOfUniqueNames object class).

Some user attributes might contain confidential information. Ensure that your directory access control is set up to prevent unauthorized access by non-privileged users.

Instant Messaging and Searching the Directory Anonymously

Instant Messaging needs to be able to search the directory to function correctly. You need to ensure that your directory is configured to be searchable by anonymous users. If your directory is not readable or searchable by anonymous users, you must take configuration additional steps.

For more information, see Chapter 11, Managing Instant Messaging’s LDAP Access Configuration, in Sun Java System Instant Messaging 7.2 Administration Guide.

Planning Instant Message Privacy, Security, and Site Policies

Instant Messaging provides the ability to control access to Instant Messaging features and preserve end-user privacy.

Instant Messaging Site Policies

Site policies specify end-user access to specific functionality in Instant Messaging. When developing your site policies for Instant Messaging, keep in mind the following questions:

• Can users access the presence status of other end users?

• Can users send alerts to other end users?

• Do you want users to save properties on the server?

• Who do you want to be able to create and manage conference rooms?

• Who do you want to be able to create and manage news channels?

For more information, see Chapter 17, Managing Instant Messaging and Presence Policies, in Sun Java System Instant Messaging 7.2 Administration Guide.

Methods of Controlling Instant Messaging End User and Administrator Privileges

Different sites using Instant Messaging server have different needs in terms of enabling and restricting the type of access end users have to the Instant Messaging service. The process of controlling end user and administrator Instant Messaging server features and privileges is referred to as policy management. You choose from two methods of policy management: through access control files or through Sun Java System Access Manager.

• Managing Policies Using Access Control Files. The access control file method for managing policies allows you to adjust end-user privileges in the following areas: news channel management, conference room management, the ability to change preferences in the User Settings dialog, and ability to send alerts. It also allows specific end users to be assigned as system administrators.

• Managing Policies using Sun Java System Access Manager. This method gives you control of the same privileges available with the access control file method; however, it additionally allows more fine-tuned control over various features, such as the ability to receive alerts, send polls, receive polls, and so forth. Furthermore, managing policies using Sun Java System Access Manager gives you finer-tuned control over privileges.

If your deployment does not include Access Manager, you must use the access control file method to manage policies. If you are using Access Manager with Instant Messaging, and you have installed the Instant Messaging and Presence services components, you can use either of the policy management methods. Managing policies using Access Manager is a more comprehensive method. One advantage of this method is that it allows you to store all end-user information in the directory.

For more information, see Chapter 17, Managing Instant Messaging and Presence Policies, in Sun Java System Instant Messaging 7.2 Administration Guide.