Chapter 9 - Ensuring Messaging Security

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Updated : June 14, 2001

Planning Guide

Abstract

By using the security features in Microsoft® Exchange 2000 Server, organizations can provide their users with secure end-to-end messaging both internally and with external parties. Through public key technology, organizations can extend their businesses to the Internet, where strong distributed authentication and secure communication are critical to business-to-business and business-to-consumer interaction. This chapter covers the planning of advanced security and cryptographic functions within Exchange 2000.

On This Page

Introduction
Introduction to PKI and KMS
Encryption Basics
Certification Authority
Secure Messaging Using Exchange KMS
Network Security
Planning Your Exchange Security
Summary

Introduction

Security standards and technologies are continuing to evolve to cope with rapidly growing networks, of which the Internet is only one example. The topic of network security itself is complex, comprising many concepts, techniques, and methods. In order to plan how you will use Microsoft® Exchange 2000 Server security, it is likely that you will need more information than is provided in standard documentation and more explanation of the various security components. This chapter will explain to you how common cryptography processes secure messages and how Exchange 2000 and Microsoft Outlook® 2000 implement these processes.

Chapter Start Point

The start point for this chapter is that you have a business requirement to provide secure communication in your Exchange 2000 deployment. This requirement may be between internal users of your organization or between your internal users and external parties. You are not necessarily using the security features in your current implementation of Exchange.

Chapter End Point

By the end of this chapter you will be aware of the security concepts, technology issues and features of Exchange 2000. In addition you will know how to plan an implementation using these facilities to achieve your secure messaging business goals.

Prerequisites

This chapter assumes that you are familiar with networking concepts, Outlook 2000, Microsoft Windows® 2000, Windows 2000 Active Directory™ service, and the Microsoft Exchange Server 5.5 Key Management Service (KMS). You should have reviewed and documented the security needs of the organization.

Resource Requirements

Because security affects almost every aspect of your Exchange deployment, you will probably find yourself needing to involve a large proportion of your Exchange 2000 deployment team. You should be looking at involving the following personnel:

Management

• Project Manager/Program Manager

• Product Manager

• Security Management

Architects/System Designers

• Active Directory Architect

• Exchange Architect/Deployment Planning/Migration Planning Specialist

• Network Analyst

• Consultants/System Integrators (may be covering the roles above)

Administrators

• Deployment Administrator

• Desktop Administrator

• Messaging/Exchange Administrator

• Network Manager/Administrator

• Infrastructure Administrator

• Intranet/Internet Administrator

• Browser Administrator

Non-Technical Personnel

• Business Decision Makers/Departmental Heads

• End Users

• Company Security Officer

You will need to report to:

• Executive sponsor (if they are not your Product Manager)

• Chief Executive Officer/Managing Director (unless your Product Manager or management sponsor is doing this for you).

For a full listing and description of all the personnel that may be involved in an Exchange 2000 upgrade project, refer to Planning Chapter 1, Overview of the Exchange 2000 Server Upgrade Planning Process.

System Prerequisites

If you are using the Key Management Server (KMS) in a previous version of Exchange, you need to have a clear understanding of how the existing KMS system is currently used within your organization in order to evaluate the potential success of the migration. The architects on your team should have a thorough understanding of the existing security architecture and the technical strategies for changing the security architecture throughout the organization.

Job Aid 1 is designed to help you with this recording and analysis process.

Click here to copy Job Aid 1 to your computer.

Introduction to PKI and KMS

Public Key Infrastructure (PKI) is a standards-based security environment interoperable with other PKI products in the Microsoft® Windows® 2000 Server operating system. Customers can deploy an integrated PKI as part of their server and desktop deployment, and manage that integrated PKI environment the same way that they manage other Windows 2000 Server security features.

In versions of Exchange prior to Exchange 5.5 Service Pack 1, the Key Management Server (KMS) acted as its own Certification Authority (CA). This meant that it was a self-contained, independent unit within Exchange capable of issuing security certificates. While its administration and maintenance was very simple, it couldn't communicate with or establish trust with other CAs. In Service Pack 1 the KMS was modified to allow it to either act as its own CA for X.509 Version 1 certificates, or to rely on a Microsoft Windows NT® operating system CA to generate X.509 Version 3 certificates.

In Exchange 2000 the KMS requires a Windows 2000 CA to generate certificates in all cases. You must now think of KMS as a system encompassing the CA Server, the Active Directory database, and the KMS database.

Design Considerations

When you install KMS you are committing yourself to architecture decisions that will have a long term impact for your PKI. It quite easy to install KMS and activate Advanced Security for your users, but you will find it very difficult to move away from a bad PKI architecture and start again. To do so would mean losing all existing encrypted data or forcing your users painstakingly to decrypt information that had been archived using legacy certificates.

In planning your KMS/PKI design, some of the factors you must consider are:

• Will you integrate your PKI with one of the commercial Certificate Authorities?

• How many CA servers will you have, and how will you logically and physically deploy them? In a web of trust? In a hierarchy?

• Who will be in charge of the system, and how will you ensure both security and continuity for your private keys? How will you deal with personnel changes? Will your root servers be offline to protect them? And so on…

• What will be your policies for key archival and recovery, not just of Exchange keys, but of all the other key types manageable with the Windows Certificate Authority? How will you manage helpdesk, education and security issues for your user community?

Until you have very clear answers to these questions, it is premature to deploy KMS, unless you are willing to do so on the basis that there is no guarantee that encrypted data will be preserved long term.

If you have already deployed KMS, you need to document your deployment thoroughly to upgrade.

Encryption Basics

There are two common types of encryption: symmetric key and public key. They differ in how they work, in how they manage keys and on the speed of the encryption/decryption process.

If you are new to security you might find the next few pages a bit hard going. Don't give up, tackle a paragraph at a time and its okay to take plenty of breaks. Now you know why they didn't teach you about encryption and security in high school.

Symmetric Key

Symmetric key encryption uses the same key to encrypt and decrypt all transmissions, usually with an algorithm such as RC2, RC4, CAST, DES, or Triple-DES. (These terms are defined in the Exchange 2000, Windows 2000, And Security Glossary.)

In symmetric key encryption, both parties must know the key used for encryption, so the key must be transferred between the users. Of course, it is best to do this using a different communication method from that which will be used for the later secured communications. If the key is transferred via different media and someone captures the data of an ensuing secure conversation, they won't have the key to decrypt it.

For example, you might put the key on a floppy disk and mail the floppy disk to a business associate, then send encrypted data over the Internet. Faxing the key would only work if the recipient had a clear fax machine and was a very accurate typist.

Public Key

Public key encryption was introduced to remove the need to transfer the key used for encryption and decryption between users. A pair of keys is generated for each user - a "Public Key" which is only used for encryption and a "Private Key" which is only used for decryption. A user's public key is shared amongst all users that need to send the user encrypted messages. Only the user has their private key, which they use to decrypt any encrypted messages they receive.

In X.500 compliant directories, public keys are published as user attributes. A users' X.509 certificates contain their public key as well as the information needed to verify it. Using this public key for the user, the sender can encrypt data that is intended for the user and only the user that possesses the private key can decrypt the secured communication.

But there is a problem. Due to the "hairy math" involved, using public keys to encrypt every message would be very costly in terms of time and processing, especially if you wanted to send the same message to multiple recipients.

To get around this problem a one-time symmetric "session" key is generated. The message is then encrypted with this session key. The session key is then encrypted with the each recipients' public key and added to the message. Using their private key each recipient can decrypt the session key. Then, using the session key they can decrypt the message.

Digital Signature

A digital signature serves as a "digital fingerprint" and ensures the identity of the sender and that the message has not been altered in transit. When a digital signature is added to a message, the message contents are used to compute a hash value. The hash value is then encrypted using the sender's private key and sent to the recipient.

The recipient decrypts the received hash value using the sender's public key. The recipient then computes the expected hash based on the message contents. If they match, then the validity of the content and the sender's identity are assured.

The following illustration should help you keep up, but now is a good time for a break because PKI Certificates are coming up next.

Message signing & verifying process

Public Key Infrastructure Components

Most PKI implementations are based on the International Telecommunications Union (ITU) X.509 standards.

X.509 Certificates

The ITU defined the X.509 standards for creating certificates that can be used to authenticate secret/public key procedures in X.500 directories by binding a user identity (username/password combination) to a public key.

Certificates do not dictate which cryptographic algorithm is used in the user's public key; they merely associate the public key and the user's identity in a verifiable way. X.509 also specifies the format of certificate revocation lists (CRLs) that administrators can use to revoke pre-existing trusts.

For example, if your organization terminates a partnership with a supplier, you might add the supplier to a CRL. This would prevent its certificates from continuing to be trusted within your organization.

Public Keys and Certificates

Public keys and X.509 certificates are not interchangeable and do not perform the same function. A public key is used to encrypt a transmission. An X.509 certificate contains and supplies verification of a user's public key. When a trusted authority signs an X.509 certificate, a user can verify the integrity of another user's public key as well as for which applications the key was granted and is valid.

Certificate Versions

X.509 V1 certificates include fields for the version number, serial number, signature algorithm ID, issuer name, validity period, user name, and public key information for the user, and also include signatures on each of these fields.

X.509 V3 certificates add fields for issuer-unique identifier; subject-unique identifier; and extensions, such as subject and issuer attributes, certification policy information, and key usage restrictions.

You can use either version to digitally sign items (to verify the sender's identity and that the contents of the item have not changed) or to encrypt items. However, you can use only X.509 V3 certificates in Secure Multipurpose Internet Messaging Extensions (S/MIME)-specific encryption and decryption operations.

Certification Authority

A certificate authority (CA) is a trusted entity that issues certificates to other entities. These entities are usually respected organizations, such as telecom operators or governments. In PKI, you do have to trust someone, despite what Mulder says.

A CA acts as a guarantor of the binding between the public key and the subject identity contained in the certificate. Different CAs may choose to verify the binding between the public key and subject through different methods so it is important to understand the authority's policies and procedures before choosing to trust that authority to vouch for public keys.

A certification authority (CA) is responsible for issuing certificates to requesters based on a set of established criteria. The criteria that a CA uses when processing a request is what is referred to as CA policy. The CA's policy will be typically published in a document known as a Certification Practice Statement (CPS)

Types of Certification Authorities

Self-signed Certification Authorities are CAs where the public key in the certificate and the key used to verify the certificate are the same, and the issuer and subject of the certificate are the same. This is the case of a root CA.

A Subordinate Certification Authority is a CA where the public key in the certificate and the key used to verify the certificates are different. This occurs when a CA issues a certificate to another CA to build a hierarchy of trusted entities. Cross certification is when one entity (user, corporation, etc…) trusts another entity's issuing CA. For example, Microsoft and Intel could cross-certify by sending their root CA certificate to each other. Neither CA is signed with the other's certificate.

A Root Certification Authority is a special class of CA, which is unconditionally trusted by a client. All certificate chains terminate at a Root CA. The decision to designate a CA as a root CA is effected by making that CA self-signed. Windows 2000 can only designate a self-signed CA as a Root CA.

Certificate Enrollment

Certificate enrolment is the procedure that a client (for example, a person or a computer) follows to request and receive a certificate from a CA. The certificate request provides identity information to the CA that subsequently becomes part of the issued certificate. The CA processes the request based on a set of criteria that may require some out-of-band authentication. If the request is successfully processed, the CA then issues the certificate to the user.

PK-based technology generally relies on certificates to bind public keys to known entities. The Windows 2000 PKI supports certificate enrollment to both the Microsoft enterprise CA and standalone CA, or to third-party CAs like VeriSign. Enrollment support is implemented in a transport-independent manner and is based on use of industry-standard PKCS-10 certificate request messages and PKCS-7 responses containing the resulting certificate or certificate chain.

Certificate Revocation

Although certificates have an pre-determined lifetime, CAs can revoke a certificate before the certificate's lifetime has expired by a process known as certificate revocation. The CA publishes the list of serial numbers of certificates that it considers no longer usable on a Certificate Revocation list (CRL).

Like certificates, CRLs also have a lifetime but this is typically much shorter than that of a certificate. The CA may also provide a reason for why the certificate should no longer be used, and a date from which this change of status is understood to apply. The set of reasons that may be given are:

• Key Compromise

• CA Compromise

• Affiliation Changed

• Superseded

• Cessation of Operation

• Certificate Hold

If the CA has revoked a certificate, it means that the CA is withdrawing its statement about the allowed usage of the key-pair prior to the certificate's normal expiration. Once the certificate which has been revoked expires, then its entry on the CRL is removed, which keeps the size of the CRL at a minimum. Thus the CRL must be kept up to date, otherwise it would allow users with invalid certificates to access resources.

During signature verification, applications can check whether a given certificate and key-pair are still completely trustworthy. If not, the application could take a view as to whether the reason or date of the revocation affects the use of the certificate in question. If the certificate is being used to verify a signature and the date on the signature precedes the date of the revocation of the certificate by the CA, then the signature may still be considered good.

Secure Messaging Using Exchange KMS

The Exchange 5.5 Key Management Service (KMS) is the communication hub between the Certificate Service, the Administrator, the Exchange-specific CSP (Crypto Service Provider), the System Attendant, and the Archive Database. It is the core component to Exchange Advanced Security , which understands and coordinates the flow of all tasks, such as enrollment, recovery, renewal, etc.

The Exchange 2000 KMS architecture is the same as it was in Exchange 5.5. KMS still uses a private database (kmsdir.edb) to store the KMS administrator accounts and passwords as well as users' private-encryption-key and encryption-certificate histories.

Exchange 2000 requires Windows 2000 Active Directory and a Windows 2000 Certificate Sever (CS). Active Directory (AD) stores user certificates, certificate revocation lists (CRLs), and encryption preferences.

Exchange uses several components to secure items:

Exchange System Manager	Manages the Advanced Security operations for an organization, including issuance and revocation of certificates, recovery of certificates and setting of site encryption algorithm preferences.
KMS Archive database	Stores private keys.
Windows 2000 Certificate Server	Windows 2000 Certificate server is required to run KMS.
Active Directory	Stores certificates/preferences for client encryption and signing. For example, clients state in the directory the maximum strength security that they support (i.e., 128-bit encryption). Others clients use this information to secure messages in ways the clients will be able to decrypt.
Client (Outlook)	The client interface to Advanced Security. It reads users' certificates from the Active Directory, performs all cryptography on mail messages, and protects private keys in a secure store on the client.

Network Security

So far you have been looking at how you can use PKI-based message security to secure the end to end delivery of messages between users. Now, let's look at the options for ensuring secure communication between servers running Exchange and your clients. There are several protocols available to you to achieve this.

IP Security (IPSec)

IPSec is an Internet public standard that provides security at the IP Transport layer (Network Layer 3). This enables protection with low CPU overhead, particularly when used with network interface (NIC) cards that provide on-board support. IPSEC provides protection in the IP and upper-layer protocols in the TCP/IP protocol suite, such as TCP, UDP, ICMP, and other protocols that send traffic at the IP layer.

IPSEC uses the Diffie-Hellman algorithm to enable key exchange, and provides the keying material for all other encryption keys. IPSEC can automatically generate new keys during communication. The communication can be sent in blocks of data, each block secured with a different key. This prevents an attacker from obtaining the entire communication with a single compromised key.

The great thing about IPSec is that because the encryption is at a packet level, the packets themselves simply appear as normal packets to routers and other hardware components. You can get network cards that offload the IPSec encryption/decryption from the processor onto the card.

Other Network Security

Other network security options include NTRPC, Secure Socket Layer encryption (SSL) and Transport Layer Security (TLS).

In these protocols a secure path is established during the network connection and is re-established each time a new network connection is made. Potentially, this makes the protocols less secure than IPSEC if a session is kept alive for a long time as attacks could be made on the session key. However, following recent changes in US export regulations, you can now use these protocols with 128-bit security in most countries (40-bit in restricted markets) which greatly reduces this risk.

NTRPC connections are based on the RSAâ„¢ RC4 stream encryption. SSL and TLS are similar to NTRPC in that they use RC4 stream encryption, but are Internet based, public standards whereas NTRPC is proprietary to Microsoft.

Due to the proprietary nature, you can typically use NTRPC only to secure communication between Microsoft based systems. However, SSL and TLS can be used to secure heterogeneous network connections between SMTP mail servers using X.509v3 certificates. In addition, SSL is often used to secure client-server connections using standard protocols such as LDAP, POP3, HTTP, NNTP, and IMAP4.

Planning Your Exchange Security

When planning Exchange security for your organization, you should review the features available in Exchange against the organizational requirements. In addition you should consider your physical and network topologies.

PKI Planning

Ensure that you locate the KM Server(s) in a physically secure location, which is still accessible for administrators to perform backups. The location of servers becomes more important when you deploy Exchange 2000 with multiple Certificate Servers and KM Servers. A well-chosen location for your CS and KM Servers can simplify backup and recovery of KM databases and the key issuance policies.

Certificate Server Planning

As Exchange 2000 uses the Windows 2000 Certificate Server to generate public keys and certificates, there must be at least one CS already deployed before you can use Exchange 2000 certificate based security . You will need to work closely with the Windows 2000 architects and administrators to ensure that the Windows 2000 CS planning incorporates your Exchange 2000 needs.

Planning a Trust Hierarchy

Before deploying your Exchange security you should decide if you need to set up any trust networks with external organizations.

First you should decide which external organizations or CAs your organization should trust, and plan to obtain their X509v3 root certificates. Make sure your plans allow for the fact that this process has to be performed on each KMS (not each CS).

Once the trust is established, you should regularly import CRLs for trusted external CAs (and send yours to them) to guarantee that revocations are reflected in the CRL. When other organizations establish trust with yours, they will request your root certificate and CRL. You can obtain them by exporting them to a file from your CS. As before, transmit these out-of-band.

Planning Cross-Certification

In Exchange 2000, Windows 2000 maintains the certificate trust lists (CTLs) for your organization, a task previously performed by KMS. This gives you the facility to add the root certificates of outside parties, such as a company you are partnered with, to your internal CTL.

If you wish to take advantage of this facility, make sure you have plans in place to obtain the certificates prior to your deployment.

Exchange Server Security Planning

You will need to decide which of the Exchange Server security options you will use. There are several options that will provide you with secure transmission, digital signature, and digital encryption:

• Options that secure transmissions by securing the underlying transmission medium (network privacy)

• Options that secure item transmission or verification of the sender's identity by securing or signing the item being transmitted (message content encryption and signing)

• Options that support session level and item level security

SMTP Security

Exchange supports three options in regard to securing SMTP message delivery between servers:

SASL and AUTH

SASL provides a simple base level of authentication and optionally allows two communicating hosts to negotiate a security protocol. Exchange supports SASL as an authentication mechanism between SMTP mail transfer hosts, and AUTH (an SMTP extension command), which similarly allows for the authentication of the connection between two mail hosts.

SASL/AUTH over SSL

When SASL and AUTH are combined with SSL, these authentication and session security techniques provide an encrypted and authenticated connection between the transfer hosts for the "clear" SMTP transfer.

Windows NT Challenge/Response and NTRPC.

Windows NT Challenge/Response is an encrypted authentication protocol used between computers based on Windows NT. If NTRPC encryption is turned on (default between servers) the communication stream between the Windows NT servers is encrypted using RC-4. This means that the SMTP mail transfer is encrypted, even though the underlying SMTP transfer format is clear text.

Message Security

Exchange provides the following options with regard to message based security.

X.509v1 Key Exchange (Item Encryption and Signing)

Exchange 2000 (and all previous versions) support the issuance of X.509v1 certificates to recipients in the Exchange organization. Using a supplied form with Exchange, the certificate exchange form, users in one organization can send their certificates to users in another Exchange organization. After certificates are swapped, the users can send and verify messages that are digitally encrypted, digitally signed, or both.

X.509v3 Key Exchange (Item Encryption and Signing)

Exchange 2000 supports the issuance of X.509v3 certificates to recipients in the Exchange organization. Using a form supplied with Exchange, users in one organization can send their certificate to users in another Exchange organization. As with the X.509v1 certificates, after the certificates are swapped, the users can send and verify messages that are digitally encrypted, digitally signed or both.

Client Security Planning

Prior to deployment you should plan who in your user base will require messaging security and how to achieve this with your preferred client(s). If you have users who need to use S/MIME for external communication, then you will need to provide them with Outlook 98 or later. However, if the users only want to sign and secure items within the organization and are not concerned about compliance with S/MIME standards, you could continue to use an older version of the Outlook or Exchange client.

Exchange 2000 provides a server-side feature that gives non-S/MIME clients two options for handling S/MIME signatures, "Preserve" or "Toss":

• Preserve S/MIME signature

If you preserve the signature Exchange stores the entire signed message in an attachment to the message. Messages go through a conversion process when they are received into the Exchange store: if even one bit is changed during this process the signature would be invalid, even though the message may not have changed. Using the preserve option and encapsulating the original mail message as an attachment preserves the signature on the item.

• Toss S/MIME signature

In this case Exchange simply removes the signature associated with the message. Using this method, S/MIME clients lose the ability to verify signatures on messages, but all clients get readable text.

Summary

In this chapter you have seen how you can plan to address the security needs of your organization through a combination of PKI-based message security and network based security. In the next chapter, you will look at Outlook Web Access, an area that will particularly benefit from effective security.

Give Us Your Feedback

We would like you to give us feedback on this material. In particular, we would be grateful for any guidance on the following topics:

• How useful was the information provided?

• Were the step-by-step procedures accurate?

• Did you use the job aids and were they useful?

• Were the chapters readable and interesting?

• Overall, how do you rate the series?

Send your feedback to the following e-mail address:

TechNet_PAG_Exchange@css.one.microsoft.com

We look forward to hearing from you.