Advanced Security in Exchange 2000, Part 2

Secure MIME (S/MIME) is the Internet’s de facto standard for secure messaging. Many organizations use S/MIME to bootstrap the rollout of a corporate public key infrastructure (PKI). In "Advanced Security in Exchange 2000, Part 1," May 2000, I introduced S/MIME’s secure messaging capabilities and reviewed the new S/MIME features in Microsoft Exchange 2000’s Key Management Server (KMS). Moving to the client side, I take a closer look at S/MIME and how S/MIME builds upon X.509 and MIME. I also review the level of S/MIME support that Microsoft’s latest messaging clients—Outlook 2000 and Outlook Express 5.0—provide, the clients’ integration with Exchange 2000’s Advanced Security, and the clients’ interoperability with Netscape mail clients. (To learn more about Windows 2000 PKI interoperability, you can download the Microsoft white paper "Windows 2000 Public Key Interoperability" at http://www.microsoft.com/windows2000/library/howitworks/security/w2kpkint.asp.)

MIME and S/MIME
An Internet mail message consists of a message header, which contains sender and recipient information, and an optional message body. Thanks to MIME, which the Internet Engineering Task Force (IETF) defines in Request for Comments (RFC) 2045 through 2049, a message body can contain data types other than flat ASCII. (For an overview of RFCs that relate to MIME and S/MIME, see the sidebar "S/MIME-Related RFCs.") You can use MIME to add nontextual objects, such as images, audio, formatted text, and Microsoft Word documents, to messages. MIME terminology refers to a data type as a content type. A multipart content type lets you embed different content types in one message body. In a multipart body, boundaries mark the beginning and end of each content type.

S/MIME provides security extensions that let MIME entities encapsulate security objects, such as digital signatures and encrypted messages. (RFC 2634 defines enhanced S/MIME security services, such as signed receipts that ensure nonrepudiation of receipt; Microsoft plans to include these services in the upcoming Office 2000 Service Release 1—SR1a, which will be the subject of a future article entitled "Advanced Security in Exchange 2000, Part 3." SR1.) S/MIME adds new MIME content types that provide data confidentiality, integrity protection, nonrepudiation, and authentication services: application/pkcs7-MIME, multipart/signed, and application/pkcs7-signature. The MIME content type application signals that the message carries data as a MIME attachment and that an application (in this case, the mail client’s S/MIME functionality) must process the data before the recipient can view it. As Table 1 shows, the attachment’s extension differs depending on the S/MIME service that the content type provides. The MIME header specifies the name of the MIME attachment. Some mail clients, such as clients of non-S/MIME-enabled systems or early versions of S/MIME, need the attachment to recognize a message’s S/MIME content. Other mail clients rely completely on the content-type information to identify MIME entities; these clients ignore the attachment names.

S/MIME secures only the message body. Header information must remain unencrypted for messages to relay successfully across gateways on the path between sender and recipient.

Clear and Opaque Signing
As Table 1 shows, you can use the application/pkcs7-MIME content type or a combination of the multipart/signed and the application/pkcs7-signature content types to sign a message body. Each application implements a different signature type: clear or opaque. These two signature types let S/MIME-enabled and non-S/MIME-enabled mail clients exchange signed messages. A clear signed message separates the digital signature from the signed data, and an opaque signed message binds the signature and the message in one binary file. Figure 1 illustrates a clear signed message format, and Figure 2 illustrates an opaque signed message format.

You can observe the difference between clear and opaque signing from Outlook 2000 or Outlook Web Access (OWA). Viewing the plaintext part of a clear signed message doesn’t require S/MIME processing. The Outlook 2000 preview pane, which Screen 1 shows, displays the content of a clear signed message, but you must double-click an opaque signed message to view the content. (Double-clicking the message prompts S/MIME to process the message.) OWA doesn’t support S/MIME, so you can view only clear signed messages from an OWA interface; opaque signed and encrypted messages show an smime.p7m attachment.

Because mail message exchanges involve a one-step protocol (i.e., no interaction takes place between the sender and the recipient before the system relays the message), the sender might not know the recipient’s S/MIME capabilities. Both S/MIME-enabled and non-S/MIME-enabled mail clients can read clear signed messages. However, opaque signed messages have an important advantage over clear signed messages because intermediate gateways can’t change the hidden plaintext section of an opaque signed message’s MIME body. When you send S/MIME clear signed messages from a Messaging API (MAPI) mail client (e.g., Outlook 2000 in Corporate/Workgroup mode) to an SMTP-MIME mail client (e.g., Outlook Express 5.0), the sending client uses MAPI rules to format the message. An SMTP gateway will transform the message to MIME format. The transformation also changes the plaintext part of the message, which causes the receiving client’s signature check to return an invalid outcome, as if an intrusion had occurred. This invalidation error occurs less often in Exchange 2000 than in Exchange Server 5.5. The Exchange 2000 streaming database stores native MIME messages, so Exchange 2000 transforms MIME messages to MAPI messages only when absolutely necessary (e.g., when a MAPI client wants to read a MIME-formatted message).

As a rule of thumb, send clear signed messages when you don’t know the recipient’s S/MIME capabilities. Send opaque signed messages to S/MIME-enabled clients or when sending messages from a native MAPI client through SMTP or X.400 gateways (e.g., messages between two MAPI clients across an SMTP site link, messages from a MAPI client to an Internet Message Access Protocol 4/SMTP—IMAP4/SMTP—client). You can select either signing method in Outlook 2000 and Outlook Express 5.0. In Outlook 2000, you set the method in the message options; in Outlook Express 5.0, you set the method in the mail client’s Advanced Security options.

Microsoft Outlook and S/MIME
Outlook 2000 is the latest version of the Microsoft full-blown mail client. Microsoft also offers Outlook Express 5.0, a lightweight Internet-oriented mail client that Microsoft distributes with Internet Explorer (IE) 5.0. You can connect Outlook Express 5.0 to Exchange 2000 or Exchange Server 5.5 through POP3 or IMAP4, and you can connect the mail client to a directory through Lightweight Directory Access Protocol (LDAP). Table 2 shows an overview of these clients’ main S/MIME features.

You can install Outlook 2000 in one of two email modes: Corporate/Workgroup or Internet Mail Only. (You can also select the No E-mail mode.) The two email modes support different protocols: Corporate/Workgroup is a complete MAPI mail client that provides additional support for SMTP and POP, and optional support for LDAP (through the LDAP Directory Service); Internet Mail Only is an ISP-oriented mail client that provides SMTP, IMAP, POP, and LDAP protocol support. You can use the Reconfigure Mail Support button in the Outlook 2000 Mail Services Options dialog box to switch between modes. Outlook 2000 reconfigures the mode at the machine level: The reconfiguration applies to every user who logs on to the machine.

From an S/MIME standpoint, a fundamental difference exists between the two modes. When you want to provide encryption key recovery for your enterprise mail clients, install your Outlook 2000 clients in Corporate/Workgroup mode. This mode lets you enroll clients in Exchange 2000 Advanced Security and lets mail clients take advantage of the S/MIME encryption preferences that Exchange 2000 stores in Active Directory (AD). "Advanced Security in Exchange 2000, Part 1" describes Exchange 2000 Advanced Security in detail.

Certificate Enrollment and Renewal
The administrator of the Exchange 2000 KMS initiates Advanced Security enrollment. The administrator generates and distributes enrollment tokens that clients can use to enroll for S/MIME certificates and keys. Every mail client that Table 2 lists can use an inhouse or a commercial Certificate Authority (CA) to enroll for a certificate, although only the KMS-CA, which is loaded with Exchange 2000-specific certificate templates, can generate Advanced Security certificates. When you use a Win2K Enterprise CA, your clients can enroll using a Web-based (http://servername/certsrv) or GUI-based (i.e., the Microsoft Management Console—MMC—Certificates snap-in) interface. If a user receives a certificate from the CA and still can’t send S/MIME-signed messages, check the user’s S/MIME settings in Outlook 2000 or check the binding between the user’s mail account and S/MIME certificate in Outlook Express 5.0, as Screen 2 shows.

Certificate renewal is as important as enrollment. Every Microsoft mail client that I mention in this article warns users when the users’ certificates expire or when the CA or KMS administrator has revoked the certificates. The Outlook 2000 Corporate/Workgroup mode, combined with the Exchange Server KMS, offers the highest level of automation: A dialog box prompts users to enroll for new certificates, which the CA transparently generates when users accept the prompt. Users of Outlook 2000 Internet Only mode or Outlook Express 5.0 must rerun the enrollment process to replace expired or revoked certificates.

You don’t need to install personal S/MIME certificates or enroll in Advanced Security to read signed messages in Outlook 2000 or Outlook Express 5.0. Outlook Express 5.0 users don’t even need a personal S/MIME certificate to send encrypted mail. When a client receives a message with a valid signature, the software automatically adds the sender to the Outlook Express Contact List. A Contact List entry contains the sender’s account certificate; after you have an account’s certificate, you can send encrypted mail to that account. Outlook 2000 requires users to manually add senders to the users’ Contact List or Personal Address Book (PAB), and users must have personal S/MIME certificates to send encrypted messages.

Directory Support
Both Outlook 2000 Internet Only mode and Outlook Express 5.0 support LDAP. Mail clients can connect to any LDAP-compliant directory and download account information, including certificates, to the clients’ PABs. Outlook 2000 Corporate/Workgroup mode can also support LDAP if you add the LDAP Directory Service to your Outlook profile. However, unlike the Outlook 2000 Internet Mail Only mode and the Outlook Express 5.0 LDAP services, the Outlook 2000 Corporate/Workgroup mode's LDAP service doesn't support the downloading of certificates from the Exchange Directory. In Outlook 2000 Corporate/Workgroup mode, you can use MAPI only to download certificates from the Exchange directory.

Win2K automatically publishes the certificate of a mail client that enrolls with a Win2K Enterprise CA as an attribute of the client’s account in AD. (Windows NT 4.0 publishes in the Exchange directory only the certificates of clients enrolled in Advanced Security.) To enable Outlook 2000 Internet Only mode to browse AD, create a new Directory Service (DS) account that connects to a Win2K domain controller through port 3268 (the Global Catalog port). At press time, Outlook 2000 Corporate/Workgroup mode can connect only to AD. Outlook Express 5.0 can browse AD by default.

Win2K automatically adds all certificates used in a user’s logon session to the user’s personal certificate store, which Screen 3 shows. The user-specific part of the certificate store is part of a user’s profile, which by default resides locally on a user’s workstation. If your organization supports roaming profiles, which you can enable from a user-account object’s properties, you can also store the profile on a central server. On a Win2K platform, all CryptoAPI 2.0-enabled applications share the certificate store. (Both Outlook 2000 and Outlook Express 5.0 are CryptoAPI 2.0-enabled.)

Outlook and Private Key Protection
Outlook 2000 and Outlook Express 5.0 use Microsoft Protected Storage, which is a Win2K system service that offers advanced software protection for private key storage—an often-overlooked crucial detail of certificate-based security. Advanced software protection helps secure private keys that you store on a system’s hard disk. But, a better solution is to store the key on a Hardware Security Module (HSM) or on a smart card. HSMs, such as Compaq’s Atalla Internet security processors, are computer cards that automatically delete stored data when an intruder tampers with the cards. Given the price of HSMs, less expensive (about $50) smart-card-based solutions, such as Gemplus’ GemSAFE User 2.0, might be a more feasible solution for client-side private key protection.

When you enroll for a certificate, use a password to protect access to the associated private key. You can use Win2K’s Syskey utility, which provides 128-bit encryption, to further protect hard-disk password storage. To look at the Syskey configuration settings, type

syskey 

at the command prompt. You can manually enter the Syskey key at system startup, store the key on a 3.5" disk, or use a complex obfuscation algorithm to store the key on the hard disk. (By default, Win2K enables Syskey and stores the key on the hard disk.)

S/MIME Certificates
S/MIME builds upon open standards such as X.509—an International Telecommunications Union Telecommunication Standardization Sector (ITU-T) standard that defines a format for digital certificates. All the latest Microsoft products support X.509 version 3 certificates. For compatibility with Outlook 97 and Exchange Server 5.0 and 4.0, Exchange 2000 also supports X.509 version 1 certificates (a subset of X.509 version 3). Win2K Certificate Server issues only X.509 version 3 certificates, but you can configure the Exchange 2000 KMS to issue X.509 version 1 or X.509 version 3 certificates.

To view the content and format of your S/MIME certificates, load the MMC Certificates snap-in for your account, open the Personal Certificates container, and double-click an S/MIME certificate. When you export a certificate to a .cer file, you can use the Certutil utility to view the certificate’s content from the command prompt, as Screen 4 shows. (Certutil is available on Win2K servers running a Win2K CA.)

Outlook 2000 and Outlook Express 5.0 can download certificates from a directory or receive certificates attached to signed mail messages. You must validate a certificate before you can use it. Outlook 2000 and Outlook Express 5.0 evaluate different criteria to determine whether you can use the certificate’s public key for cryptographic S/MIME operations. (For more information about certificate validation, see the sidebar "Certificate Validation.")

S/MIME Interoperability
While writing this article, I experienced problems when I sent signed messages from an Exchange 2000 Advanced Security-enrolled user to Netscape Messenger and Outlook Express 5.0 users. The problem’s cause was the RFC 822 name check. (For more information about this check, see the sidebar "Certificate Validation".) A certificate that you issue using the KMS doesn’t contain the certificate subject’s RFC 822 name; instead, the subject field contains an X.500 distinguished name (DN), such as CN=Jan,CN=Recipients,CN=AMTG Administrative Group,O=Compaq. Also, the certificate doesn’t contain a Subject Alternative Name field. To resolve the problem I experienced, the Win2K Certificate Server must issue S/MIME certificates that set the Subject Alternative Name field to the subject’s RFC 822 name.

On an NT 4.0 platform, you might experience problems building an interoperable S/MIME solution that consists of several Certificate Servers linked together in a certificate hierarchy. Microsoft has learned a lot from these problems. IE 5.0, Outlook Express 5.0, Outlook 2000, and Windows 2000 Professional (Win2K Pro) all come with enhanced support for certificate validation in CA hierarchies (based on certificate-chain validation).

From an interoperability standpoint, the most important non-Microsoft S/MIME client is Netscape Messenger. Messenger ships as part of Netscape Communicator. One of Messenger’s strengths is that it supports a range of non-Microsoft platforms, including UNIX and Linux. At press time, Communicator 4.7 doesn’t support certificate revocation list (CRL) distribution points (CDPs) to automate CRL checks. Netscape plans to embed this important extension in future releases of Communicator. Netscape’s latest certificate server—Certificate Management System (CMS) 4.1—already has the ability to embed the CDP extension in all the certificates that the CMS issues. Netscape also plans to support dual key pairs and data recovery. CMS 4.1 comes with a new component called the Data Recovery Manager that you can use to archive and recover private encryption keys. The North American version of CMS 4.1 comes with a Communicator 4.5 Dual-Key Test Bed plugin that lets Communicator deal with dual key pairs. Another interesting detail about the Netscape mail client is that users can’t choose between clear and opaque signing. By default, Netscape Messenger sends clear signed messages.

Enhanced S/MIME Support and Interoperability
Outlook 2000 and Outlook Express 5.0 (on the client side), combined with Exchange 2000 (on the server side), have the potential to become Microsoft’s first mature S/MIME platforms. Both platforms benefit from the Win2K PKI and provide enhanced S/MIME security options and extensive S/MIME interoperability with non-Microsoft mail clients. In a future article entitled "Advanced Security in Exchange 2000, Part 3," I'll talk about the S/MIME updates in Outlook 2000 SR1a.