Messaging systems can contain all sorts of information. Exchange Server lets you store nearly any type of file in user mailboxes or public folders. Because you don't want other people browsing through your mailbox or accessing public folders that they shouldn't, maintaining a reasonable level of security is in your best interest. This article examines the essential aspects of security within an Exchange environment and Exchange 5.0's advanced security features.
Mailbox Security
Before an Exchange server accepts any request to connect, the client must
provide satisfactory credentials. The client establishes credentials when it
attempts to connect to the Information Store service. At that point, it must
provide the name of a known Windows NT account and its password. If the user has
already logged on to the network and has credentials (the access token an NT
domain controller grants), the Exchange server uses those credentials and
doesn't display a logon screen. Screen 1, shows a logon in progress.
A user must log on if credentials are not available, if the server has rejected the existing credentials (e.g., the account has been locked out since the last logon), or if the client is set to ignore any existing security data during logon. The last check box on Screen 2, determines whether Exchange will use the existing credentials.
Clients never transmit password information during logons; instead, both client and server do everything on the basis of a shared secret--the account password. At the simplest level, the server encrypts text with the password and sends the encrypted string to the client, which uses its knowledge of the password to decrypt the string. The client then sends the decrypted string back to the server, which checks the return value against its original transmission. If both strings match, the server accepts the credentials and establishes an authenticated connection. Of course, this interchange does not use a simple text string. The interchange incorporates some additional one-time data to stop hackers from decrypting intercepted strings.
Similarly, a shared secret maintains security within a site. In this case, the secret is the name and password for the Exchange service account. Without knowledge of the secret for the service account, you can't install a new server into a site. Exchange checks the name and password when the Exchange services (such as Mail Transfer Agent--MTA, store, and system attendant) start after a system reboot. Without the secret, a rogue server cannot join a site and begin to replicate data you'd rather not share.
NT accounts that hold the appropriate permissions can override basic mailbox security and connect to a mailbox. This feature is beneficial in some cases, such as when people leave the organization and you want to recover messages from their mailboxes. This feature is a problem in other cases, such as when systems administrators gain unauthorized access to mailboxes to read mail they shouldn't. Exchange logs all such accesses in the NT event logs with identifier 1016; a good idea is to regularly check the event logs for such instances.
Administrative Permissions
Sometimes Exchange administrators get confused between NT's admin
and permissions admin permissions. The difference is simple: The
admin permission lets an NT account perform administrative functions for
Exchange, such as starting an Exchange service or maintaining the contents of
the directory. The permissions admin permission inherits all the power of the
admin permission and lets an NT account grant other permissions to itself and
other accounts. Permissions admin can be dangerous; for example, rogue
administrators can give themselves Send As permission on a mailbox, which lets
them connect to a mailbox and send messages as if they were the mailbox's real
owner. Exchange's advanced security features prevent rogue access to messages
secured through encryption, but they can't stop an administrator connecting to a
mailbox if the administrator has that permission. The lesson here is simple:
Don't allocate permissions admin to anyone without good reason.
Sensibly deployed, NT permissions can provide another level of protection. For example, NT administrative permissions are required only to install or upgrade Exchange software. They are not required for day-to-day administration tasks on an Exchange server. Therefore, you can allocate different levels of permissions to different administrators and restrict the most powerful permissions to a select group. If you use this restriction, you prevent rogue Exchange administrators who gain unauthorized access to users' mailboxes from covering their tracks by clearing the NT event logs--assuming, that someone actually checks the event logs to uncover such instances.
Exchange and Outlook clients (Messaging API--MAPI--clients) connect to the Exchange server with remote procedure calls (RPCs). By default, the RPCs transmitted between client and server are not encrypted; however, a setting on the client can cause the RPCs to be encrypted with a 40-bit algorithm when connected either over a LAN-type connection or via dial-up networking. The degree of protection increases to 128-bit encryption for NT clients connected to NT 4.0 servers, but only if both are running the North American edition of NT 4.0 Service Pack (SP) 2 or later. The Advanced tab shown in Screen 2 is set to encrypt information passed over the network. Using encrypted RPCs prevents an eavesdropper from reading an intercepted RPC without a great deal of effort at the cost of additional overhead. The overhead isn't enormous and probably wouldn't be noticed by users connected by a LAN; however, when users are connected over a slow dial-in link, the overhead is more noticeableand encryption is even more desirable.
Public Folder Security
The permissions for each public folder control that folder's security. You
set permissions either through the Exchange administration program or through
the client--select the Permissions tab from the folder's Properties dialog box,
as shown in Screen 3.
Clients connect to one or more mailboxes. Exchange always knows a primary mailbox and uses the full directory name (an X.500-like name) for the primary mailbox to gain access to public folders. A full directory name, also known as a distinguished name (DN), looks like this example:
Cn=Digital Equipment Corporation;cn=Dublin;cn=Recipients;cn=TonyR
Once you know a little about Exchange organizational design, interpreting the DN is easy. The example mailbox belongs to an organization named Digital Equipment Corporation; it's held in the Recipients container of the Dublin site, and the mailbox belongs to a user whose alias name is TonyR.
When a client attempts to access a public folder, Exchange checks the DN against the folder's access control list (ACL). The ACL lists DNs and the permissions they hold, so Exchange can easily validate whether a user can access a folder, and identify the user's level of access. Exchange 5.0 simplifies life because it lets you replicate a whole set of permissions through the tree of a folder and its subfolders.
Because distribution lists reside in the directory, they have DNs, too. Users inherit access permissions for a folder by their membership in a distribution list. Using distribution lists to control access to public folders is very effective, because you avoid amending individual memberships as people join or leave an organization or as responsibilities change. Exchange uses a system of backward pointers to link individual membership to a distribution list, so any permission change is active for all users as soon as you make the change. Also, you can offload distribution list maintenance to users and free a systems administrator's time.
Screen 3, shows the ACL for the Exchange Server Information public folder. Many of the entries in the ACL are for individual mailboxes, but the entry whose display name is Technical Direct is a distribution list that my consulting group uses to grant read-only access to the folder.
Exchange's AdvancedSecurity Features
Exchange has two major advanced security features: message encryption and
decryption, and digital signatures. Exchange's advanced security features are
based on software that Microsoft has licensed from both Entrust Technologies and
RSA Data Security, augmented with new or modified code developed within
Microsoft. Exchange divides the security workload between clients and server.
Clients perform all encryption and decryption and apply digital signatures. The
server keeps track of the users who are entitled to use advanced security and
management operations, such as the allocation and revocation of security
certificates. I'll describe these certificates and the part they play in
advanced security later in this article.
Mail applications usually secure email through asymmetric encryption, which uses a pair of keys--one private and one public. The keys share a mathematical relationship, but deriving one key from the other is extremely difficult. Therefore, distributing a user's public key to anyone who wants to send that user encrypted messages is safe and doesn't compromise the private key. The user views the encrypted information with the private key.
With a single-use bulk key generated on demand, Exchange encrypts message contents in a symmetric encryption, which means that Exchange uses the same key for encryption and decryption. The bulk key uses a 40-bit, 56-bit, or 64-bit algorithm, depending on the country in which the software is licensed. The 56-bit and 64-bit algorithms are only available in the US and Canada; France permits no encryption software.
Historically, the US banned the export of strong encryption algorithms on the basis that foreign parties could use encrypted data against US interests. Exchange 5.0 complied with the US restrictions in place at the time the software shipped. In June 1997, Microsoft obtained a license to export 128-bit encryption technology, and the company will use the stronger algorithms in Web-based commerce, specifically in extensions to the SSL (Secure Sockets Layer) and transport-layer security (TLS) protocols. Microsoft will incorporate the new algorithms into Internet Explorer (IE) and Internet Information Server (IIS), but the company has not made an announcement in relation to Exchange.
Additionally, each recipient's public key encrypts the encryption key for the message. In effect, this layer of encryption creates a lockbox or outer wrapper for the message. The algorithm that builds the lockbox is based on 512 bits and is much stronger than the base encryption.
Because of the computational power required, using such strong encryption is realistic only when encrypting a small amount of data. The message recipient uses the private key to open the lockbox, retrieve the bulk key, and decrypt the message. In effect, a hybrid combination of symmetric and asymmetric encryption protects messages. The bulk encryption algorithm is either CAST (from Entrust) or DES, while the public-key algorithm is RSA.
Digital signatures are like an electronic stamp or seal placed on a document. The seal affirms that a particular person, or someone with access to that person's private signing key, has sent the message. You can create a checksum for the message by feeding the message contents through an algorithm and encrypting the result with a private key to create a digest of the message. You can verify the checksum at any time by decrypting the digest with a user's public key. If anyone has changed the message content since it was sent, the checksum fails. Thus, digital signatures allow non-repudiation of messages, provide a level of confidence that a known individual sent the message, and guarantee that messages have arrived in the same form the originator sent. Exchange uses the MD5 algorithm (from RSA Data Security) for digital signatures.
The Exchange Certification Authority
I've mentioned private and public keys often. Because of the way Exchange
manages keys, you must think through how you'll deploy Exchange's advanced
security features.
Exchange uses two pairs of keys--one pair for digital signatures and the other pair for message encryption. To hold the public and private keys, Exchange uses a system of X.509 certificates, which a Certification Authority (CA) issues and controls. In an Exchange organization, the Key Management (KM) Server is the CA. Only one KM Server can issue certificates in an organization. The first KM Server you install creates the CA object in its site configuration container as Screen 4 shows. As you replicate configuration data between sites, the other sites in the organization learn of the existence of the CA, thereby preventing another KM Server from creating another CA.
You must be certain that you install the first KM Server in the right place. Because the server hosting the KM Server holds the security database for your organization, you need to physically secure and protect it from unwanted interventions.
The Exchange directory stores the X.509 certificates. When a user mailbox is enabled for advanced security, Exchange stores the X.509 certificate information as attributes of the mailbox. Each certificate requires about 700 bytes of memory. Before an Exchange or Outlook client tries to send an encrypted message to a recipient, it checks to see whether an X.509 certificate exists. If the certificate is unavailable, the client refuses to send the message. X.509 certificates hold the public key for a recipient, so if the public key is unavailable, a message cannot be encrypted.
Although logical, this approach is sometimes difficult for users to understand, especially if they try to send a message to a distribution list that has both Exchange and external recipients. In this scenario, Exchange encrypts the message for the Exchange recipients who have enabled advanced security, but Exchange won't send an encrypted message to the external recipients because Exchange doesn't know their public keys.
Similarly, the check against the directory lets the client determine what encryption algorithm to use for a message. If a North American client sends a message to other people who also use North American clients, the client can use 56-bit or 64-bit encryption; however, if an international client is involved, the client automatically downgrades to 40-bit encryption.
Holding Private Keys
Exchange holds users' private keys in an encrypted password file (with .epf
extension) on a PC. You must keep this file in a directory that's accessible
regardless of the PC the user logs on from. You may need to update your logon
scripts so that password files follow users around. Exchange encrypts the
password file as shown in Screen 5, using a secret algorithm based on a password
provided when a client enables advanced security. The key information is
meaningless to human beings.
The first time a user attempts a secure operation during a client session, the user must complete the dialog box shown in Screen 6. Note the check box to control whether Exchange prompts for a password for each operation or for each session. If this file is lost or unavailable, a user cannot encrypt, decrypt, or digitally sign messages.
Obviously, setting up and administering advanced security requires some effort. You must authorize users and issue credentials. Individually enabling hundreds of users can be time-consuming; fortunately, the SIMPORT utility can help you issue many temporary security credentials at once. However, temporary credentials don't give users access to Exchange advanced security; they merely make the beginning of the process easier. Users must complete the process with the Set up advanced security option on an Exchange or Outlook client. Eventually, the CA issues the necessary certificates, and your users can encrypt away.
After the CA issues security certificates, managing them is largely automatic. Each certificate has an expiration date, and when the date approaches, the system prompts the user to contact the KM Server for an update, as shown in Screen 7.
Management tasks include ensuring that the KM Server service starts up each time the server reboots, revoking certificates from users whose access you want to deny, and reissuing certificates for people who have lost their certificates. Recovering keys is one of the KM Server's critical functions--without this function, users can lose their .epf files or forget their passwords and be unable to read any encrypted mail. If a user loses or can't remember a password, the KM Server restores the keys, letting the user get back to work.
This workload isn't very time-consuming, and you can perform most of the tasks through the Exchange administration utility. You can appoint someone to act as the security administrator for the organization so that users have one contact for all security issues.
Working Offline
Working offline is one of the greatest benefits of using Exchange. As a
frequent traveler, I create, read, and answer messages on my notebook PC in
airport lounges throughout the world. The ease and power of Exchange's offline
capabilities simplify these tasks. If you've deployed advanced security, you can
even encrypt and decrypt messages offline because you can download the X.509
certificate information (and other directory information) into the offline
address book (OAB).
The OAB is a set of five files stored in the Windows directory. When you download details from the Exchange directory, you can choose to include details about recipients, as Screen 8 shows; the extra details include the X.509 certificates. Downloading full details takes a little extra time, but it's the only way to handle encrypted messages. OAB information is static, and you need to download a new OAB every week or so to update certificate information.
Person-to-Person Key Exchange
Person-to-Person Key Exchange (PPKE) is new in Exchange 5.0. This feature
lets people send a certificate containing their public keys to users in another
Exchange organization, as shown in Screen 9. After organizations exchange keys,
they can exchange encrypted messages. Users can hold the key information in a
personal address book (PAB), but keeping it there renders it static data. If a
certificate is revoked or altered, Exchange does not automatically replicate the
change to PABs; mail encryption stops.
Third-Party Security Products for Exchange
Exchange's advanced security features provide all the protection most users
need. However, some users require even better security, and that's where
third-party security extensions can help. People usually use third-party
extensions to get two kinds of security features: algorithms that are harder to
break and the ability to exchange key information with people who don't use
Exchange.
As I noted earlier, Exchange supports 40-bit, 56-bit, and 64-bit encryption algorithms. However, because of US government restrictions, the 40-bit algorithm is the only one available to someone like me, who doesn't live in the US or Canada. I'd like my mail to be as secure as anyone else's; however, data encrypted with a 40-bit key can be decrypted with less effort than you might imagine. The basic rule of encryption is that the longer a key is, the harder it is to break. Until Microsoft opts to exploit its new license to use 128-bit encryption inside Exchange, anyone outside the US or Canada who wants highly secure mail must look beyond Exchange advanced security.
Third-party security products belong to one of two camps: products that depend on a CA similar to the one Exchange uses and products that use public and private key pairs and rely on personal administration and distribution of the keys. The best-known example of the second approach is Pretty Good Privacy (PGP). The CA style provides the basis for almost all SSL and other Web-based security today, because managing security is easier when you have a central point of reference. Personally distributing keys is difficult to manage in a large-scale or distributed enterprise, and the system relies heavily on user cooperation and knowledge.
More and more products appear in this space all the time, and notable recent arrivals include MailSecure for Exchange (Baltimore Technologies) and Secure Messenger for Exchange (Deming Software). Both products are plug-ins to the Exchange or Outlook MAPI clients and add security options to the client menus. Both products use the Secure MIME (S/MIME) protocol to send encrypted messages between users of any mail system that supports S/MIME. Of course, any public and private key scheme works only when users make their public keys available to their intended correspondents, so both MailSecure and Secure Messenger can generate and distribute keys, much like the PPKE feature in Exchange. The combination of S/MIME support and the ability to distribute keys makes these keys well-suited for a heterogeneous messaging environment or for implementing advanced security between two Exchange organizations.
MailSecure is especially interesting for installations outside the US because the encryption algorithms did not originate in the US, and therefore, the US government cannot restrict them. Instead of the 40-bit algorithm Exchange currently offers, MailSecure uses a 128-bit algorithm, which provides a huge increase in security. A CA is available for MailSecure (UniCERT). The CA is an important component of a secure mail system, so its availability is an important plus for MailSecure.
These products aren't the only offerings on the market. Entrust Technologies' Entrust/Express extension for both Exchange and Outlook clients is in beta testing. A browse through the Exchange mailing list reveals a number of PGP extensions for Exchange. Most of these extensions are shareware or freeware, but commercial products based on PGP are also appearing.
Third-party security plug-ins cost money. Expect to pay between $50 and $100 per license, depending on the quantity you buy. Inevitably, you will face some questions about buying third-party software when Exchange provides advanced security in the base product, so be ready to justify your decision. Also, keep in mind that client technology evolves; make sure that your selected vendor is able and willing to keep its software up-to-date. Be sure to factor the cost of upgrades into your decision.
Plan Before You Deploy
We've covered a lot of ground in this article, and I hope you can use the
information to fine-tune your organization's security or help you decide
how to best deploy secure mail in your enterprise. The important thing to
remember is to plan first before plunging into deployment.
| Contact Info |
|
Secure Messenger Deming Software * 408-567-5168 or 800-454-4674 Web: http://www.deming.com |
|
MailSecure and UniCERT Baltimore Technologies * 353-1-605-4399 Web: http://www.baltimore.ie |
|
Entrust/Express Entrust Technologies * 613-247-3411 Web: http://www.entrust.com/express.htm |
