Sun Java Communications Suite 5 Deployment Planning Guide

Planning Messaging User Authentication

User authentication enables your users to log in through their mail clients to retrieve their mail messages. Methods for user authentication include:

Plain Text and Encrypted Password Login

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 Messaging Server administration. See the Directory Server documentation to understand directory server password policies:

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

An administrator can set a messaging configuration parameter to determine if plain passwords are allowed or if passwords must be encrypted. For more information, see the service.xxx.plaintextminciper (where xxx is http, pop, or imap) parameter in the Sun Java System Messaging Server 6.3 Administration Reference. The RestrictPlainPasswords option provides the equivalent function for the MMP

Both plain text and encrypted password login can be used with POP, IMAP, and Messenger Express user access protocols.

Authentication with Simple Authentication and Security Layer (SASL)

SASL (RFC 2222) provides additional authentication mechanisms for POP, IMAP, and SMTP user access protocols. Messaging Server has SASL support for the user access protocols listed in Table 13–3:

Table 13–3 SASL Authentication User Access Protocols Support Matrix


	Plain	Login	CRAM-MD5	Digest-MD5	Certificate	APOP
SMTP AUTH	Yes	Yes	Yes	Deprecated	Yes	-
POP	Yes	-	Yes	Deprecated	Yes	Yes
IMAP	Yes	-	Yes	Deprecated	Yes	-
HTTP (Messenger Express)	Yes	-	-	-	Yes	-

Note –

When using CRAM-MD5, passwords must be stored in plain text format in the LDAP directory server.
Digest-MD5 was never supported by the MMP and its use is deprecated in other cases.
To use APOP, CRAM-MD5 or DIGEST-MD5, passwords must be stored in plain text format in the LDAP directory server.

If you use SASL, user name and passwords are not encrypted unless SSL is used for the session. (For more information on SSL, see Encryption with SSL.) The SASL mechanisms, PLAIN and LOGIN, encode authentication information, but can be easily decoded if captured. Despite this limitation, SASL is useful because it can be combined with SMTP AUTH (described in Enabling Authenticated SMTP) to allow only authenticated users to relay mail through your system. For example, legitimate users can authenticate to the SMTP server, and the SMTP server can then be configured to switch to a different channel. In this way, the message from an authenticated session can come from a different TCP channel than a user that did not authenticate. A message from a user in your internal network can also be switched to differentiate it from a message coming from other sources just based on the IP address of the incoming connection.

For more information on SASL, see Chapter 23, Configuring Security and Access Control, in Sun Java System Messaging Server 6.3 Administration Guide.

Enabling Authenticated SMTP

By default, the standard SMTP port (25) is for mail transfer only. Mail relay for submissions from external networks is disabled and authentication is disabled. By default, the standard SMTP submit port (587) is for mail submission and requires authenticated SMTP. As many mail user agents still use port 25 for submission by default it might be useful to enable SMTP authentication on port 25 for those clients.

By default, users need not submit a password when they connect to the SMTP service of Messaging Server to send a message. You can, however, enable password login to SMTP in order to enable authenticated SMTP.

Authenticated SMTP (also referred to as SMTP AUTH) is an extension to the SMTP protocol. Authenticated SMTP allows clients to authenticate to the server. The authentication accompanies the message. The primary use of authenticated SMTP is to enable local users who are not in their office to submit mail without creating an open relay that others could abuse. The AUTH command is used by the client to authenticate to the server.

Authenticated SMTP provides security in sending messages with the SMTP protocol. To use authenticated SMTP, you do not need to deploy a certificate-based infrastructure. (Certificates authentication is described in Certificate-based Authentication with Secure Sockets Layer (SSL).)

With authenticated SMTP, the client can indicate an authentication mechanism to the server and perform an authentication protocol exchange.

If you require SMTP AUTH for mail submission, turn on appropriate logging, so any mail abuse can be traced.

For more information on authenticated SMTP, see the MTA chapters of the Sun Java System Messaging Server 6.3 Administration Guide.

Certificate-based Authentication with Secure Sockets Layer (SSL)

Messaging Server uses the SSL protocol for encrypted communications and for certificate-based authentication of clients and servers. This section describes certificate-based SSL authentication. For information on SSL Encryptions, see Encryption with SSL.

SSL is based on the concepts of public-key cryptography. Although TLS (Transport Layer Security) is functionally a superset of SSL, the names are used interchangeably.

At a high-level, a server which supports SSL needs to have a certificate, a public key, a private key, certificate, key, and security databases. This helps assure message authentication, privacy, and integrity.

Table 13–4 describes the SSL authentication support with each client access protocol. This table shows whether a secure session (startTLS) could be started up over a insecure channel and whether a separate secure channel (SSL on Separate Port) is provided.

Table 13–4 SSL Authentication Support Matrix


Protocol	startTLS	SSL on Separate Port
SMTP	Yes	Yes
POP	No	Yes
IMAP	Yes	Yes
POP over MMP	No	Yes
IMAP over MMP	Yes	Yes
SMTP over MMP	Yes	Yes
Webmail	No	Yes

The SMTP, POP, and IMAP protocols provide a way for the client and server to start communication without SSL, and then switch to it by using an equivalent startTLS command. The SMTP, POP, and IMAP servers can also be configured to use SSL on an alternate port, for clients which do not implement startTLS.

To authenticate with SSL, the mail client establishes an SSL session with the server and submits the user’s certificate to the server. The server then evaluates if the submitted certificate is genuine. If the certificate is validated, the user is considered authenticated.

If you use SSL for authentication, you need to obtain a server certificate for your Messaging Server. The certificate identifies your server to clients and to other servers. Your server can also have any number of certificates of trusted Certificate Authorities (CAs) that it uses for client authentication.

Some protocols require use of the SASL EXTERNAL mechanism in conjunction with the SSL client certificate to move from un-authenticated to authenticated state.

For more information on SSL, see Chapter 23, Configuring Security and Access Control, in Sun Java System Messaging Server 6.3 Administration Guide.