While transport security is the low-hanging
fruit of messaging security, it's not appropriate for all situations.
The big problem with transport security is that it only covers
hop-to-hop security. Within your Exchange organization, you can assume
that all your message traffic will be handled securely. Once you hand
off a message to an external system, though, you lose all control over
it. Even if they use TLS, you have no guarantee that some party isn't
intercepting messages within the server process.
If you need to ensure that your messages are secure
from endpoint to endpoint, you have two options with Exchange 2010: the
Secure Multimedia Internet Mail Extensions (S/MIME) standard, or
rights-managed messages using the built-in integration with the Windows
Rights Management (RMS) service.
1. S/MIME
The S/MIME standard was originally developed in 1995
by a consortium of security vendors amidst a number of competing
standards. In 1998, the S/MIME group submitted a draft of S/MIME v2 to
the IETF standard process. This change helped propel S/MIME to the
leading message security contender. S/MIME v3 followed in 1999 to
provide additional enhancements that had been identified. S/MIME v3 is
described in three RFCs: RFC 2632, RFC 2633, and RFC 2634. This version
of S/MIME is widely accepted and supported by a number of products,
including previous versions of Exchange Server.
Although Exchange 2007 allowed the use of S/MIME with
Outlook clients at RTM, it required SP1 to permit S/MIME support in
OWA. In Exchange 2010, the necessary OWA support is present in the
release version — although because it relies on ActiveX, you can only
use it with Internet Explorer, not any of the other browsers that are
otherwise supported by the premium version of OWA.
S/MIME in Exchange doesn't involve a lot of
server-side configuration on the Exchange side of things. The bulk of
administrative work for S/MIME is tied up in your PKI and client
operations. You need to be able to issue S/MIME certificates, and you
must place those certificates where clients can access them. For
Exchange and Outlook, this typically means some sort of Active
Directory–integrated PKI. You can, of course, issue S/MIME certificates
using the Windows Certificate Services (as it's known in Windows Server
2003; in Windows Server 2008, it's renamed Active Directory Certificate
Services). However, you can use any other X.509v3 standards-compliant
PKI solution that you wish (or already have in place).
S/MIME provides two security services:
Digital Signatures
These allow the sender to perform a signing
operation on the email message. The recipient can then validate this
signature. Digital signatures provide the benefits of authentication (the recipient can be certain the sender is who they claim to be), nonrepudiation (the sender cannot claim that they did not sign the message), and integrity (by ensuring the message contents have not been altered, which would cause the signature to no longer match).
Message Encryption
This allows the sender to ensure that the message
contents cannot be viewed by anyone who does not possess the private
key that corresponds to the recipient's digital certificate. While a
regular email message can be read by anyone who can access it in transit
or in storage, an encrypted message is not so vulnerable. Encryption
provides the benefits of confidentiality (the contents of the messages remain confidential even through untrusted systems and hops) and integrity.
When users choose to use S/MIME, they can apply
either digital signatures or message encryption, or both. They are
neither mutually exclusive nor automatically combined.
|
Company CDEF experienced a small-scale phishing
attack where their customers were solicited via email by an outside (and
unauthorized) party to visit a website and provide customer
information. The executives of this company wanted a way that anyone
receiving an email from one of their users could verify the authenticity
of the message.
A rather hastily prepared plan involved standing up a
Windows Certificate Server and issuing S/MIME certificates to all of
their users. They then required their users to digitally sign messages
that they sent to their customers.
While the messages arrived at the customer and were
digitally signed, there was one drawback. The certificate authority that
issued the certificates was not trusted by the customers and thus the
authenticity of the sender could not truly be authenticated.
While this might have worked if Company CDEF were
only concerned with sending to a single, external organization it did
not work in this case. They could ask the remote organization to "trust"
their own certificate authority.
A better and more trustworthy way to issue S/MIME certificates is to get them from a trusted certificate authority.
|
Typically, Exchange 2010 does not directly handle
S/MIME certificates, perform S/MIME signing or encryption functions, or
otherwise interact with the PKI; it leaves these activities to the
client applications. In an Exchange system, there are three main types
of clients:
The Outlook application is a member of the
Office application family and provides a rich set of functionality when
used with any email system, including support for the S/MIME standards.
If user certificate enrollment is automatic (such as through the use of
Group Policy or logon scripts) and stored in Active Directory, Outlook
can automatically look up user certificates for other users in the
organization. For external users, the certificates must be saved and
applied to the contact object.
The
Outlook Web App client is part of Client Access role of the Exchange
Server system and is the only Exchange component that directly interacts
with S/MIME. As stated previously, OWA requires a separate ActiveX
control to handle S/MIME certificates, restricting it to users who use
the Premium OWA client on Internet Explorer.
The
Pocket Outlook application on Windows Mobile 6.1 clients can make use
of S/MIME when connecting to Exchange using the Exchange ActiveSync
protocol. All current Windows Mobile devices that run versions 6.1 and
above should support the S/MIME functionality.
In addition, many other third-party clients also support S/MIME. Check with your vendor for details.
2. Rights-Managed Email
Windows has provided a Rights Management Service for
several years now, and with Windows Server 2008, it's been folded into
the Active Directory as Active Directory Rights Management Service
(AD-RMS). RMS provides a native Windows information rights management
(IRM) capability. RMS-enabled applications such as the Office family of
applications give their users the ability to create and apply
certificate-based protection policies to their documents or email
messages. These policies go beyond the binary "read/don't read"
functionality provided by S/MIME and give you a far more granular set of
permissions and abilities:
You can control the specific actions
recipients and readers can take with the protected content, including
reading, modifying, printing, and forwarding.
You can define expirations and revocations for any rights-managed content.
You can easily define different levels of permissions for different users or groups.
You can create and manage RMS policies to define standard categories of information, such as Company Confidential.
With Exchange 2010, you can integrate your Exchange
servers into your RMS deployment using the new ControlPoint integration
with the Windows Server 2008 AD-RMS role. In addition to your Outlook
users being able to apply RMS policies and rights to their own messages,
you can also define transport rules in your organization that
automatically apply specified RMS policies to matching email messages.
With the new RMS federation functionality in Windows Server 2008, you
can even federate your RMS deployment with other Windows organizations,
allowing your contents to be delivered externally and still be protected
to the same degree. AD-RMS also provides the ability to interoperate
with a per-individual Windows Live–based RMS service, giving you the
ability to designate any recipient who has a Windows Live account.
Exchange 2010 includes one RMS template out of the
box: the Do Not Forward template permits only the designated recipient
to decrypt and access the message contents. The RMS client (and either
Outlook or OWA) prevents the end user from forwarding the protected
message to other recipients, copying the contents of the message into a
new message, or printing out the message. Of course, RMS cannot prevent
the user from re-typing the message or telling someone over the phone
what he or she has read. RMS cannot completely stop bad behavior.
There's another option for message security that is
common in environments that run a combination of Windows and other
platforms: the Pretty Good Privacy (PGP) package. Originally an end-user
solution for performing ad hoc encryption of files, several mail
clients provided support and allowed the same technology to be used to
protect email messages. While PGP gained adherents, the technology was
encumbered by some of the RSA algorithm patents, so the open source
community wrote an independent implementation called Gnu Privacy Guard
(GPG). For more information about GPG, see www.gnugp.org.
GPG uses the same basic mechanisms and can be compiled to use the
proprietary RSA algorithms if the organization owns a license (or wants
to pay for one), but GPG uses unencumbered protocols and code.
Over time, the commercial PGP solution added the type
of centralized policy control and key management functions that large
organizations need. You can't deploy a solution to thousands of
mailboxes and clients if you can't keep track of encryption keys in a
coherent, centralized manner. It interoperates with major mail clients,
providing the kind of message security functionality equivalent to
S/MIME but without the reliance on X.509v3 digital certificates. Many
organizations view PKIs with alarm and would rather not have to deploy
one if they can avoid it; PGP seems to be a great solution.
However, this seeming simplicity may not be what you
think. In reality, PGP is a PKI — it's just not one based on the X.509v3
standard. What this means is that if you ever need an X.509v3 PKI
deployed, you'll be managing two PKIs, not one. It also means that
interoperability with other organizations can't be assumed; you have to
ensure they also support and use PGP and make provisions for your PGP
keys to be available. With S/MIME and X.509v3, you need to make
provisions to publish your CA certificates and your CRL, but after you
do so, any other organization that has deployed S/MIME can easily start
taking advantage of message security to your organization.
In the end, it comes down to your business
needs. If you have partners that use PGP and you need to interoperate
with them, PGP may be the right solution for you. But for most
organizations these days looking for comprehensive message security, we
think they're better off looking at the other two options we've
discussed.
