17.2 Secure mail using SMIME

17.2 Secure mail using S/MIME

In this section we look at how Microsoft has built S/MIME support into Exchange 2003, Outlook Web Access, Outlook Express 6.0, and Outlook 2003, and how this support can be integrated with Windows Server 2003 PKI.

17.2.1 S/MIME basics

Secure MIME (S/MIME) is an Internet standard for secure messaging. It can add data authentication, confidentiality, nonrepudiation, and integrity protection to MIME-formatted messages. The IETF standardized S/MIME version 3.0 in RFCs 2632 through 2634.

From a cryptographic point of view, S/MIME is an excellent example of a hybrid cryptographic solution. The basic S/MIME operation is illustrated in Figure 17.11. In a typical S/MIME scenario, Alice wants to send a secure message to Bob. Secure in this context means guaranteeing confidentiality, integrity, data authentication, and nonrepudiation.

Figure 17.11: Basic S/MIME operation.

The S/MIME exchange illustrated in Figure 17.11 can be split into six steps, as follows:

• Step 1: Alice creates a digital signature for the message using her private key.

• Step 2: Alice encrypts the message using a bulk encryption key.

• Step 3: To create a secure channel protecting the confidentiality of the encryption key, Alice encrypts the encryption key with the public key of Bob. This results in a lockbox.

• Step 4: Bob decrypts the lockbox using his private key. This results in the bulk encryption key.

• Step 5: Using the bulk encryption key, Bob decrypts the message.

This gives Bob the readable message.

• Step 6: Bob verifies the authenticity and integrity of the message by verifying the digital signature using Alice’s public key.

S/MIME builds on MIME. Thanks to MIME, which the IETF defined in RFCs 2045 through 2049, the body of a mail message can contain data types other than just flat ASCII. An Internet mail message typically consists of a message header, which contains sender and recipient information, and an optional message body. 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 into a single 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 message blobs.

To do so, S/MIME adds new MIME content types that provide data confidentiality, integrity protection, nonrepudiation, and authentication services. These content types are called application/pkcs7-MIME, multipart/ signed, and application/pkcs7-signature. The MIME content type provides information about the type of data a message carries in its MIME attachments. By doing so, an application (in this case, the mail client’s S/MIME logic) can know how it must process the MIME data before it displays them to a user.

As Table 17.5 shows, the S/MIME attachment’s extension differs depending on the S/MIME service 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 in the message header to identify MIME entities. 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.

Table 17.5: S/MIME Content Types and Services

MIME Content Type	MIME Subtype	S/MIME Type	S/MIME Service	Attachment Extension
Application	pkcs7-MIME	Signed data Enveloped data	Guarantees data integrity, data authentication, and nonrepudiation. Uses opaque signing. Guarantees data confidentiality.	.p7m p7m
Multipart	signed	N/A	Guarantees data integrity, data authentication, and nonrepudiation. Uses clear signing.	N/A
Application	pkcs7-signature	N/A	N/A	.p7s

17.2.2 Exchange Server S/MIME support

From version 4 onward, Microsoft Exchange Server has included the Advanced Security subsystem to let users secure their mail messages using S/ MIME. Microsoft built Advanced Security around the optional Key Management Service (KMS). This is still true for Exchange 2000, but is not true anymore for Exchange 2003. In Exchange 2003, the KMS functionality has been merged into the Windows Server 2003 Certification Authority (CA).

In its early days, the KMS was a CA, an RA, and also the entity taking care of key archival and recovery. From Exchange 5.5 Service Pack 1 onward, you can outsource the KMS CA functionality to a Windows CA. In Exchange 2003, the CA and archival and recovery functions have been moved to the Windows Server 2003 CA. From Exchange 2000 onward, Exchange’s S/MIME functionality is also tightly integrated with AD. AD stores user certificates and certificate revocation lists (CRLs).

Exchange Advanced Security has always included a key recovery feature that lets you recover copies of users’ lost or deleted encryption keys. In Exchange Advanced Security, key recovery is server-oriented. The KMS database contains copies of each Advanced Security–enabled user’s current and previous private encryption keys. In an Exchange 2003 environment, the key recovery function is provided by the Windows Server 2003 CA. This was explained in Chapter 15. This chapter also included information on how to migrate encryption keys from the KMS database to the CA database.

The presence of a key recovery system explains why Exchange KMS and S/MIME in general use a dual-key-pair system. In a dual-key-pair system, users have one key pair for encryption operations and another pair for signing operations. Exchange Advanced Security and S/MIME could not guarantee trustworthy digital signature services if they used a single key pair and stored the pair’s private key in a central database for key recovery purposes. Digital signatures require that only users can access their private signing keys (otherwise, anyone could impersonate the user). Therefore, Exchange Server stores the signing pair’s private key only on the client side. Note that not all S/MIME product vendors support the dual-key-pair system.

Because the KMS does not exist anymore in Exchange 2003, there is very little you can configure when setting up S/MIME for your mail clients. In the properties of a mailbox store, there is a checkbox that says “Clients support S/MIME signatures.” This checkbox must be checked if you want to enable your clients to use S/MIME (the checkbox is enabled by default). This configuration option is illustrated in Figure 17.12.

Figure 17.12: S/MIME configuration in Exchange 2003.

17.2.3 Microsoft mail client S/MIME support

Both the full-blown Outlook mail client and Outlook Express have offered S/MIME support for quite some time. Brand-new to Exchange 2003 is the S/MIME support for Outlook Web Access (OWA). Outlook 2003 is the latest version of Microsoft’s full-blown mail client. Outlook Express 6.0 is a lightweight Internet-oriented mail client that Microsoft distributes together with Internet Explorer (IE) 6.0. You can connect Outlook Express 6.0 to Exchange 2003, Exchange 2000, or Exchange Server 5.5 through SMTP and POP3 or IMAP4, and you can connect it to a directory through LDAP. OWA allows for HTTP-based mail access from a browser—the OWA Web pages and logic are included with the Exchange 2003 code. Table 17.6 gives an overview of the Microsoft mail clients’ main S/MIME features.

Table 17.6: Outlook Client S/MIME Features

	Outlook 2003	Outlook Express 6.0	Outlook Web Access
Mail Connectivity Protocol	MAPI/RPC, POP3, IMAP4, SMTP, HTTP	POP3, IMAP4, SMTP	HTTP
Encryption key recovery	Yes (if combined with a Windows Server 2003 CA)	Yes (if combined with a Windows Server 2003 CA)	Yes (if combined with a Windows Server 2003 CA)
CRL Distribution Point (CDP) support	Yes	Yes	Yes
Private key storage	Data Protection API, optional Syskey	Data Protection API, optional Syskey	Data Protection API, optional Syskey
Support for clear and opaque signing	Yes	Yes	No, only clear signing
Support for secure receipts	Yes	No	No
Support for security labels	Yes	No	No
Certificate Provider	KMS, internal CA, commercial CA	Internal CA, commercial CA	Internal CA, commercial CA
Certificate renewal	Can be automated (if using Windows Server 2003 and XP user autoenrollment)	Can be automated (if using Windows Server 2003 and XP user autoenrollment)	Can be automated (if using Windows Server 2003 and XP user autoenrollment)
LDAP support	Yes	Yes	No

Of the three mail clients, Outlook 2003 is certainly the most complete when it comes to S/MIME functionality. It comes with support for some of the S/MIME enhanced security services (explained later) and includes easy- to-use digital ID management features. For example, from Outlook 2003 you can publish your digital ID (certificate) to the Exchange Global Address List (the Global Catalog) and request a new digital ID with an online CA.

When you click the Get a Digital ID… button in the Outlook 2003 Security Options, Outlook redirects you to the Office Marketplace Web site. From there you can, for example, request a digital ID with the United States Postal Services (USPS). To publish your personal certificates to the GAL, go to Tools, Options, Security Options, and select Publish to GAL… To disable this feature, change the Registry setting HKEY_LOCAL_ MACHINE\SOFTWARE\Microsoft\Office\11.0\Outlook\Security\PublishToGalDisabled (REG_DWORD) to 1. Table 17.7 gives an overview of other Outlook 2003 S/MIME settings that can be controlled through registry settings. All of the settings are located in the HKEY_LOCAL_ MACHINE\SOFTWARE\Microsoft\Office\11.0\Outlook\Security registry folder.

Table 17.7: Outlook 2003 S/MIME-Related Registry Settings

Setting	Type – Value	Meaning
AlwaysEncrypt	REG_DWORD – 0,1	When set to 1, all outgoing messages are encrypted; corresponds to Encrypt message content and attachments GUI checkbox.
AlwaysSign	REG_DWORD – 0,1	When set to 1, all outgoing messages are signed; corresponds to Add digital signature to this message GUI checkbox.
ClearSign	REG_DWORD – 0,1	When set to 1, clear signing is used for all outgoing messages, corresponds to Send this message as cleartext signed GUI checkbox.
RequestSecureReceipt	REG_DWORD – 0,1	When set to 1, secure receipts are requested for all outgoing messages, corresponds to Request S/MIME receipt for this message GUI checkbox.

Exchange 2003 adds S/MIME capabilities to OWA. To use S/MIME in OWA, you must run IE 6 with Service Pack 1 or later. You enable OWA support in the configuration options of your OWA client. When you enable it, an ActiveX control providing the S/MIME logic will be down- loaded from the OWA server to your client. You must be a power user or local administrator to install the control. If you are using OWA from different machines, you will have to enable it (and download the ActiveX control) on every machine (as illustrated in Figure 17.13). When one user has downloaded the control to, for example, a kiosk machine, it will be available to all users of that machine. OWA users can obtain S/MIME certificates in exactly the same way as when they are using Outlook 2003 or Outlook Express 6.0: All of the certificate enrollment methods described in Chapter 15 also apply to OWA S/MIME. Once users have enabled their OWA client to use S/MIME, the OWA interface and message properties will be extended to add digital signatures and encrypt the message content. A very nice feature of the OWA S/MIME support is that all certificate- related processing (such as revocation checking) is done on the Exchange 2003 server side. By default, all OWA traffic occurs over a secured HTTP over SSL communication channel (https).

Figure 17.13: Setting up OWA S/MIME support.

17.2.4 Clear and opaque signing

As Table 17.5 showed, 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. An opaque signed message binds the signature and the message in one binary file. Figure 17.14 illustrates the difference between a clear and an opaque signed S/MIME message.

Figure 17.14: Clear versus opaque S/MIME signing.

Both S/MIME-enabled and non-S/MIME-enabled mail clients can read clear signed messages. Opaque signed messages can only be read by S/ MIME-enabled mail clients. Opaque signed messages have an important advantage over clear signed messages because intermediate gateways cannot change the hidden plaintext section of an opaque signed message’s MIME body.

When you send S/MIME clear signed messages from a MAPI mail client (Outlook 2003) to an SMTP-MIME mail client (Outlook Express), 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 and Exchange 2003 than in Exchange Server 5.5. The Exchange 2000 and Exchange 2003 streaming database stores native MIME messages, so Exchange 2000 and Exchange 2003 transform 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 do not 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 IMAP4/SMTP client).

You can select either signing method in Outlook 2003 and Outlook Express 6.0. In Outlook 2003, you set the method in the message options or in the global security options (as illustrated in Figure 17.15). In Outlook Express 6.0, you set the signing method in the mail client’s Advanced Security options (as illustrated in Figure 17.16). Outlook Web Access only supports clear signing.

Figure 17.15: Setting opaque and clear signing message properties in Outlook 2003.

Figure 17.16: Setting opaque and clear signing message properties in Outlook Express 6.0.

17.2.5 Enhanced Security Services

RFC 2634 specifies four optional security service extensions, also known as Enhanced Security Services (ESS), for S/MIME. These services include secure receipts and security labels. Microsoft supports some of these extensions in Outlook 2003 and Outlook Express 6.0. The extensions were first introduced in SR1a for Outlook 2000.

Secure receipts (which you should not confuse with Outlook’s delivery receipts or read receipts) provide “nonrepudiation of reading,” giving you cryptographic proof that the intended recipient has read and verified a signed message. A secure receipt is signed, meaning that when you receive a message and reply to it using a signed or secure receipt, you sign the receipt using a private key. You cannot deny having done so because only you can access and use it. A secure receipt takes three steps in its travels. First, you generate and send a message, specifying a secure receipt. Next, the recipient responds to the secure receipt request. Finally, you receive the secure receipt.

You can set the secure receipt request for signed only or signed and encrypted messages. The message can be clear or opaque signed. You cannot make secure receipts receiver-dependent—if you set “Request S/MIME receipt for this message,” it applies to all recipients. Also, secure receipts always return to the message’s sender; it is not possible to set another return mailbox. You can make secure receipts the default by checking the “Request S/MIME receipt for all S/MIME signed messages” box in Outlook’s security options.

By default, Outlook 2003 automatically sends a secure receipt when you open the message and when the system can cryptographically verify the message signature. If you add the Registry value HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Office\11.0\Outlook\Security\RespondToReceipt- Requests (REG_DWORD) and set it to 1, Outlook prompts you before sending a secure receipt: “A request has been made to send an S/MIME receipt when the message has been verified. Do you want to send an S/ MIME receipt?”

To verify a secure receipt—to cryptographically verify the receipt’s signature and instruct Outlook to check the receipt’s content against the original—you must open the receipt. If the original message is not in the Sent Items folder, Outlook prompts you to find it. If you cannot find the original message, the secure receipt verification fails. If verification succeeds, Outlook 2003 automatically adds tracking information to the original message, as Figure 17.17 shows. Tracking information enables easy and centralized receipt status checking.

Figure 17.17: S/MIME signed receipt tracking information.

A security label, a kind of tagging system for e-mail messages, defines a message content’s sensitivity. As with secure receipts, you can set security labels on signed messages. The power of the security label feature lies in its ability to restrict a user’s access to a mail message, which is a standard requirement for messaging systems in military environments. The military, which does not want a sergeant—even if that sergeant is a system administrator—to have access to a general’s mail, conceived of many of the concepts that RFC 2634 defines and SR1a implements.

In Outlook 2003, Microsoft provides a UI that lets you attach security labels to the messages you send. In addition to the UI, you need two things to implement security labels: (1) security policy modules, which define the classification levels, and (2) client-side logic, which enforces the security labels based on a user’s classification level. Because security policies differ for each organization, Microsoft does not provide the logic for security labels out of the box. Microsoft provides a sample policy and a policy module design document in the MS Office SDK.

17.2.6 S/MIME and other SMTP security aspects

When you are planning for a complete SMTP security solution, you should look after more than just an S/MIME implementation. You must also think about content blocking, virus scanning, user blocking, and mail archiving:

• Content blocking deals with policy enforcement on mail content.

Exchange 2003 comes with important new SPAM-blocking functionality. Content blocking support can also be found in products from companies such as Tumbleweed and Symantec.

• User blocking enables you to define rules on the SMTP gateway level to determine to which internal or external recipients users can send mail messages and from which internal or external senders users can receive mail messages. This functionality is also included in Exchange 2003. Products offering content blocking typically also provide advanced user-blocking functionalities.

• Virus protection (AV) software scans mail messages for viruses. A best practice is to provide virus scanning on different levels and to use different scanning engines (remember the principle of defense in depth). Numerous AV products are available that can integrate with Exchange 2003 and Outlook 2003 (Symantec, McAfee, and Antigen).

• Mail archiving copies every incoming and outgoing message into a special archival repository. Archiving is a legal requirement in many companies. Archival solutions for Exchange are available from companies such as Ixos, CommVault, KVS, and Essential.

An important detail to keep in mind is that end-to-end encryption and AV/content scanning are mutually exclusive. You can, however, combine the three security requirements by implementing encryption on the gateway level. This means that a message will be scanned for viruses and on content before it is encrypted, and vice versa for incoming messages. Products that can offer S/MIME functionality on the gateway level are available from companies such as Tumbleweed and ZipLip.