Network Computingwww.networkcomputing.com

Best supported by Qualcomm, KPOP is technically a separate protocol from POP3, running on a separate TCP port number. KPOP integrates into a Kerberos versions 4 and 5 architecture as a kerberized service, meaning that it requires its own--or a host--principal in the Kerberos database.

KPOP suffers from the complexity plaguing all Kerberos applications. KPOP clients must access the workstation's Kerberos ticket-manager utility (the client component) to request and present users' authentication tickets. With no common Kerberos client API on Mac or Windows systems, implementing KPOP means matching Kerberized POP clients, such as Eudora Pro, with the right implementation of the Kerberos client.

SSL POP/IMAP
Why add the complexity of a challenge/response algorithm when you can brute-force encrypt the entire session? With SSL (and for capable servers, TLS [Transport Layer Security]-encrypted POP and IMAP use the same well-known ports as their unencrypted counterparts), you can encrypt a session at Layer 5.

Implementing SSL for POP and IMAP is identical to setting up an SSL Web server. Generate a key pair for each protocol, have the public key certificate signed by a trusted certificate authority (CA) and install the signed key. From then on, specify SSL support in your client, and POP and IMAP sessions are fully encrypted.

We tested SSL POP and IMAP services on a Microsoft Exchange Server (5.5 Service Pack 2) using the IIS 4.0 Key Manager utility to install the appropriate client-side SSL certificates. SSL is well supported in most major POP and IMAP servers and is easy to set up given access to an X.509 version 3 CA or a public CA, such as VeriSign.

Enabling SSL IMAP and POP, as well as HTTP, LDAP and SMTP under IIS, is as simple as generating, signing and installing a server certificate. In the lab, we used Xcert's Sentry CA to establish a local certificate authority, which we used to sign the various server certificates. First we selected the SSL encryption option on the client--Microsoft's Outlook/Outlook Express or Netscape's Communicator, for instance--and POP or IMAP sessions were automatically encrypted.

This option masks not only the password, but the entire session, placing an extreme load on your POP or IMAP server. Large SSL POP or IMAP implementations should consider implementing external POP or IMAP proxies to distribute the load. At the very least, hardware-based encryption accelerators will lighten the load.

SSL encrypts the entire TCP stream, so it's not a challenge/response authentication system. It doesn't affect existing authentication functions; it merely relies on standard plain-text authentication under its own veil of cryptography.

SASL: CRAM-MD5 and NTLM
Perhaps the best solution to clear-text authentication is the IETF's SASL. A modular security layer, SASL lets the client and server negotiate from one of multiple authentication schemes. By default, SASL specifies a plain (clear-text) authentication method, but most SASL solutions implement CRAM-MD5. This challenge/response protocol is similar to APOP, but can be applied to multiple Internet protocols.

Although SASL is not a commonly supported protocol, it is perhaps the best hope for future protocols. By standardizing the authentication layer among Internet protocols, SASL should do for TCP sessions what PAM (pluggable authentication modules) did for Unix systems.

CRAM-MD5 SASL implementations are scarce, but SASL will probably provide strong authentication options soon because of its addition to other Internet protocols, such as LDAP3.

We were surprised to find Microsoft taking advantage of SASL in its own Secure Password Authentication protocol--in Exchange Server Outlook 98/Outlook Express. It's not a standardized SASL authentication method, but Microsoft uses SASL as a gateway to access its proprietary Windows NT challenge/response protocol (NTLM). A checkbox implementation in Outlook 98 and Outlook

Express, SASL/NTLM authentication lets Microsoft desktop applications leverage existing NT Domain defenses to securely authenticate to Exchange Servers via POP or IMAP. It's another proprietary solution.

Looking Ahead
Although VPN technologies are most often used to tunnel external users through a firewall and into a protected network, this does little to protect against packet snooping on the internal network. In most cases, SSL's overhead is overkill for most POP and IMAP users (unless users' mailboxes contain sensitive data), whereas Layer 3 encryption can provide an effective alternative to securing authentication sessions. It should be each protocol's responsibility to provide secure authentication services--with the deployment of point-to-point IPSec VPNs, this may soon be a moot point. Point-to-point IPSec may be an alternative worth exploring: It will be featured in the Microsoft 2000 OS and will be enabled by other technologies, such as hardware IPSec processing from NIC vendors including 3Com Corp.

Dan Backman is senior systems consultant at Sarcom, a systems integrator. Send your comments on this article to him at dbackman@sarcom.com.