Secure Messaging with Microsoft Exchange Server 2000

If you use a network monitor to watch an IM conversation, what you’ll essentially see is a Hypertext Transfer Protocol (HTTP) conversation over port 80. Exchange IM uses Rendezvous Protocol (RVP), a forerunner of the Internet Messaging Presence Protocol (IMPP). RVP builds a protocol on top of the Web Distributed Authoring and Versioning (WebDAV) standard, meaning that all RVP exchanges are actually Extensible Markup Language (XML) blobs that can easily be read in transit. Because of the way the client and server communicate, however, there is relatively little you can do about it.

As it turns out, the Exchange IM client isn’t the only client that can be used with Exchange. There are three separate clients to be aware of, and even though they’re similar in many ways, there are some subtle differences:

• The standard Exchange IM client, available from the Exchange 2000 product CD, can only talk to the Exchange IM server because it only supports RVP. It runs on Microsoft Windows 95, Windows 98, and later versions and supports text-based messaging (although it integrates with the Microsoft NetMeeting client for video and audio conversations). However, the Exchange client was designed with a plug-in architecture that allows you to add an MSN Messenger plug-in so that the same client can simultaneously connect to both services. The latest version of the client adds voice and video capabilities, and is available from http://www.microsoft.com/exchange/downloads/2000/imclient.asp.

• The MSN Messenger client, available for Windows 98 and later versions from http://messenger.msn.com, uses MSN’s proprietary protocol to implement text, voice, and video chat, file transfers, and application sharing. The basic MSN Messenger client cannot talk to Exchange IM servers; it lacks the plug-in capability of the Exchange IM client.

• The Windows Messenger client, included with Microsoft Windows XP, is the code base from which future IM clients will probably be drawn. Windows Messenger includes three plug-ins that provide connectivity for MSN Messenger, Exchange 2000 IM, and generic Session Initiation Protocol (SIP)-based services.

A fourth possibility is not yet realized: third-party vendors like Trillian (http://www.trillian.cc) have released clients that can simultaneously use multiple IM systems, including MSN Messenger. Since the specification for the Exchange IM protocol is public, no one is stopping these folks from making their clients Exchange-aware, so perhaps they will. One final note: If you have UNIX, Linux, Mac OS, or other systems, you’re mostly out of luck. Apart from Windows, only Mac OS X has an MSN Messenger client, and it is not presently capable of talking to Exchange IM servers.

Most people think of IM as a text-only service; it turns out that all of Microsoft’s clients support video, text, and audio chats, as well as file transfer and application “whiteboarding.” No matter what method you’re using to communicate, the basic sign-in process for the Exchange IM client always proceeds as follows:

1. The client requests a Domain Name System (DNS) service (SRV) record for the IM domain. By convention, Microsoft recommends using im.yourdomain.com, but as long as you’ve manually created the SRV record so it points to your “real” domain, you can call it whatever you like.

2. The client retrieves the Internet Protocol (IP) address of its IM home server. Think of the home server like a mailbox server: each IM client is assigned to a single home server, and that server acts as a controller and coordinator for IM traffic for that client. The home server is a Windows 2000 server with the Exchange IM component installed; it can be an Exchange 2000 server or a standalone box.

3. The client sends its authentication request to the home server using HTTP authentication. As with Outlook Web Access, the client can request digest (obscured), or NTLM authentication, but the IM server administrator is free to choose which authentication methods the server supports. (The client always tries NTLM authentication first, falling back to digest mode if that fails.)

Once the client has logged in, the home server registers its IP address, contact list, and a TCP port above 1024 so that it can send notifications using the WebDAV NOTIFY verb. Let’s say Alice wants to send a message to Bob, another user on her Exchange IM system (but not necessarily on the same IM home server!). She composes and sends the message, which goes from her client to her home server. The home server determines Bob’s home server and sends the message to it, and it delivers the message to Bob. The process is slightly different for the case where Alice and Bob have accounts on two different Exchange organizations; in that case, the message goes from Alice’s home server to the IM router designated for Bob’s network. That router then proxies the request to Bob’s home server, which sends it to his client.

Notice that this description doesn’t say anything about whiteboarding, application sharing, or voice or video communications. Those protocols all use peer-to-peer connections (using the NetMeeting application programming interfaces [APIs]), with minimal involvement from the home server.

Why Bother?

IM use restrictions usually fall into two camps: companies seem to either want to prevent everyone from using any kind of IM, or they want to prevent the use of IM outside their network perimeter. There are good reasons for these kinds of restrictions, including the following:

• Legal requirements in the financial services industry (and other industries in various countries outside the United States) mean that companies must be able to archive all communications with customers so that regulators can inspect them. It’s easier to just cut off the communications channel, or at least prevent it from being used to talk to customers, than to buy and install monitoring software, so many firms are doing just that.

• The U.S. health-care industry is subject to a complex set of regulations that require privacy controls on most doctor–patient communications, including IM. These requirements echo in some ways the data privacy laws common in European countries, which can also impact the use of IM.

• The native file transfer functionality built into most IM systems means that users on your networks probably have the ability to accept untrusted files from untrusted sources—all without content inspection or virus scanning. Organizations that do allow IM frequently block the file transfer features of the IM services they allow; there are also content-scanning products that scan transferred files for malicious content before allowing the transfer to finish. As an alternative, Reuters and Bloomberg both offer closed, nonpublic IM systems that don’t allow file transfers at all, but these systems tend to have limited utility for most organizations.