Q Mentioned>
9/03/99 - Securing POP and IMAP Sessions
Sep. 03, 1999 (Network Computing - CMP via COMTEX) -- Over the router and through the net, to the mail server we go..."
Unfortunately, if Little Red Riding Hood were anything like your users, she"d have been screaming out the key code to grandma"s door
as she skipped through the woods. No wonder the wolf ate her. Yes, POP3 and IMAP4 are the standard protocols of choice, but like
most Internet protocols, they default to plain-text authentication. And instead of sending push-flagged packets like telnet, both wrap the
user"s password within a single password-usually accompanied by the oh-so-cryptic verbs "pass" or "authenticate."
The obvious answer is to use transport-level encryption services, such as IPSec (IP Security) or other VPN (virtual private network)
technologies, but these mainly protect against packet captures outside the firewall. Whether or not we like to admit it, most attacks
originate inside the firewall. To be effective, network protocols should use some form of challenge/response protocol that never sends
the actual password across the wire. Until point-to-point IPSec encryption becomes a reality, guarding your users" passwords should
be a serious concern. The vendor community has recognized this problem and has presented various solutions for non-clear-text POP
and IMAP authentication.
When we tested non-plain text authentication protocols for use in POP and IMAP services at our Real-World Labs(R) in San Mateo,
Calif., we found that many products work exactly as billed, but a lack of standardization makes each a single-vendor solution.
In terms of interoperability, SSL POP and IMAP offer the best support, with client support from Microsoft Corp. and Netscape
Communications Corp. Qualcomm"s implementations of APOP (Authentication POP) and KPOP (Kerberos POP) can be convincing in
the right environments, but like Microsoft"s NTLM (NT LAN Man) via SASL (Simple Authentication Security Layer) authentication
scheme, both offer limited cross-vendor support. Finally, SASL gives us a glimpse into the future of IP authentication and it"s being
rolled into LDAP and other protocols.
APOP
POP in RFC 1460 defines an MD5-based challenge/ response authentication algorithm dubbed APOP. A simple example of
challenge/response authentication is that it adds a challenge string to the normal POP server. The client responds with a hash of that
challenge and the user"s password (see "Challenge/ Response Authentication," at
www.networkcomputing.com/1018/1018ws2side1.html). If the client"s response matches the server"s own hash, the user is
authenticated. The hash isn"t reversible, so the user"s password isn"t compromised when sent over the network.
Despite APOP"s appearance in the RFC, Qualcomm is the only vendor to support it. We were surprised and disappointed to find that
Microsoft"s Outlook Express and Outlook2000 POP3 support does not include APOP authentication. But if you"re willing to stay inside
Qualcomm"s product line, APOP is an excellent choice for strong POP authentication. We tested APOP using Qualcomm"s Eudora
Pro 4.1 and qpopper, Qualcomm"s Unix POP daemon.
Enabling APOP is easy. APOP is added as a configuration option when the qpopper POP3 daemon is compiled (like much Unix
software, qpopper is distributed in source-code form). From then on, the administrator must define a separate APOP authentication
database using the popauth command and must add a password for each user. After that, users connecting to the server must use
APOP-capable clients.
Be aware that APOP must hash the user"s password in combination with the server"s challenge, so the POP server must maintain a
separate authentication database for APOP users. Although qpopper provides the popauth utility for database administration (it also
lets users reset their own APOP passwords), it means users must manage yet another password.
KPOP
For those sites that have invested in Kerberos authentication services, KPOP is a viable option for strong POP authentication.
Implementing KPOP-a ticket-granting authentication protocol-solely for POP authentication is, to say the least, masochistic.
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 -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. |
