Introduction......................................................................................................................... 4
Encryption basics................................................................................................................. 4
Symmetric (secret) key vs. public key
cryptography:................................................................ 4
What is cryptographic hashing?............................................................................................. 5
Certificates/Certificate Authorities and
authentication:............................................................. 5
What is the difference between a public key
and a X.509 certificate?..................................... 5
A description of X.509 certificates:..................................................................................... 6
What is the difference between X.509v1 and
X.509v3 certificates?........................................ 6
Network privacy vs. message content
encryption............................................................. 7
Network
security options:...................................................................................................... 7
NT RPC
Security:.............................................................................................................. 7
Secure Socket Layer encryption (SSL):............................................................................... 8
Authentication mechanisms for secure Exchange
connections:.................................................. 8
Message content encryption and signing:................................................................................ 9
Message body encryption:................................................................................................. 9
Digital signatures:........................................................................................................... 10
Securing items in Exchange............................................................................................... 12
Exchange Administrator (KMS) functions:.............................................................................. 12
Key generation (enrollment):........................................................................................... 17
Key renewal:.................................................................................................................. 21
Key recovery:................................................................................................................. 22
Key revocation:............................................................................................................... 23
Archive database details:.................................................................................................... 23
The Exchange Directory:..................................................................................................... 24
Client functions:................................................................................................................. 25
Exchange KMS implementation details.............................................................................. 26
Upgrading pre-5.5 SP1 KMS implementations................................................................... 27
Deploying Exchange Security............................................................................................ 29
Establishing a trust hierarchy:.............................................................................................. 30
Scenarios for Exchange Server security........................................................................... 30
Secure Transmission.......................................................................................................... 31
SASL/AUTH with SSL Encrypted Connection (No
Item Encryption/Signing)............................ 31
NT Challenge/Response and NTRPC Connection
(No Item Encryption/Signing)....................... 32
Digitally Signed or Sealed Items........................................................................................... 32
X.509v1 Key Exchange (Item Encryption and
Signing)......................................................... 32
X.509v3 Key Exchange (Item Encryption and
Signing)......................................................... 33
Session and Item Encryption................................................................................................ 33
SASL/AUTH with SSL Encrypted Connection
(X.509v1 Item Encryption and Signing)............... 33
NTLM Encrypted Connection (X.509v1 Item
Encryption and Signing)..................................... 33
SASL/AUTH with SSL Encrypted Connection
(X.509v3 Item Encryption and Signing)............... 33
NT Challenge/Response and NTRPC Connection
(X.509v3 Item Encryption and Signing):........ 33
Definitions.......................................................................................................................... 34
References and Acknowledgments:.................................................................................. 36
Appendix A: Knowledge Base Articles about KMS............................................................ 37
Exchange 4.0 was the first version that
allowed users to secure messages (via digital encryption) and seal/sign them
(via digital signature). Security standards and technology continue to evolve
rapidly as needs are intensified by rapidly growing networks, of which the
Internet is only a single example. And the topic of network security itself is
complex, comprising many concepts, techniques, and methods. Not surprisingly,
users sometimes need more information than is provided in standard
documentation, more explanation of what various security components are
supposed to do and how. This section explains how common cryptography processes
secure messages and how Exchange and Outlook implement them.
There are two common types of
cryptography: symmetric key and public key. They differ in how they execute and
how they manage keys.
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 and other terms are defined at the end of this chapter.)
When considering symmetric key encryption, both parties in the communication
must have the key used for encryption.
This key must be transferred between the users, and this is best done
over separate media. If the key is transferred via separate media, and someone captures
the data, they won’t have the key to decrypt it, and vice versa. For example,
you can put the key on a floppy and snail-mail it to a business associate, then
send encrypted data over the Internet.
Public key encryption was introduced to
eliminate the need to transfer the key between users. It generates a key pair
for each user: a public key for encryption (only) and a private key for
decryption (only). In X.500 compliant directories, public keys are published as
user attributes; users’ X.509certificates
contain their public key as well as the information needed to verify it.
Hashing secures message and private key
data by using them as elements in a mathematical function that creates a
digital fingerprint or “checksum” of the package. The algorithm then is used on
the receiving end to decrypt. Hash algorithms include MD-4, MD-5, and SHA-1.
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 for a user’s public key. When an X.509 certificate is signed by a
trusted authority, a user can verify the integrity of another user’s public key
as well as what applications the key was granted for and is valid for.
By 1993 the International
Telecommunications Union had defined X.509 standards for creating certificates
that can be used to authenticate secret/public key techniques 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, company A terminates a partnership with company B. The
Company A administrator can add Company B to a CRL which prevents its
certificates from continuing to be trusted within Company A.
Version 1 X.509 certificates include fields
for: version, serial number, signature algorithm ID, issuer name, validity
period, user name, public key information for the user, and signatures on each
of these fields. Version 3 certificates add support for issuer unique
identifier, subject unique identifier, and extensions such as subject and
issuer attributes, certification policy information, and key usage
restrictions. Either of these versions can be used to digitally sign items
(verify sender identity and that the contents of the item have not changed) or
encrypt items.
When transferring messages you can use
network security or message item security. These techniques are very different.
Network level secures a transmission path for multiple “clear” items. It is
established along with the network connection and re-established each time a
new network connection is made. Message level secures a specific item for
routing over a clear or encrypted transmission pipe.
Exchange supports two network security
mechanisms: NTRPC and SSL. Message content encryption and signing techniques
are performed on each item with public and private key information obtained
from the Exchange Directory or stored in the user’s private security file, on
their machine or a floppy.
Windows NT 4 uses RSA™ RC4
stream encryption to provide both secure network and PPTP VPN connections. You
can use this connection for encrypted SMTP mail, which is by definition sent as
plain text between NT servers hosting Exchange Servers. If you configure
Exchange 5.0 and 5.5 SMTP connections to use NTRPC, you can establish 128-bit
secure connections between servers in North America, and 40-bit connections
elsewhere. RPC encryption automatically negotiates the encryption level based
on the lowest level of encryption used in the connection. The SMTP connection
can be authenticated by NT challenge/response authentication when using this
option. If you require a secure client-server connection, you can enable NTRPC
on Exchange and Outlook 32-bit clients.
Similar to NTRPC, SSL also uses RSA RC4
stream encryption to secure client-server and server-server connections,
providing (for all client-server platforms) 128-bit encryption within North
America and 40-bit encryption elsewhere. It provides a secure network
connection for SMTP mail between servers. Authentication is provided through
X.509v3 certificates or by using SASL in Exchange 5.5 later. SSL can also
secure client-server connections for LDAP, POP3, HTTP, NNTP, and IMAP4.
Several mechanisms can authenticate
Exchange server-server and client-server communications:
|
Mechanism:
|
Used
for:
|
Description:
|
|
Basic authentication
|
Server-to-Server or client-to-Server
|
Plain text ID and password sent over
wire
|
|
SASL/AUTH
|
Server-to-Server
|
Plain text ID and password sent over
wire
|
|
NT challenge/response authentication
|
Server-to-Server or client-to-Server
|
The user’s password is never sent on
the wire. The username, password, and
machine name are verified based on a “shared secret” between the server and
the client.
|
|
Secure Socket Layer (SSL) server
authentication
|
Server-to-Server
|
Client trusts servers certificate
primarily to establish channel encryption
|
|
SSL client authentication
|
Server-to-Server or client-to-Server
|
Server trusts clients certificate
(ex: Web shopping, membership)
|
Digital signatures and digital sealing
are based on encryption technologies. However, Exchange uses different pairs
for each task in its implementation of these technologies. See the section
below on Key Generation (Enrollment)
for more details on the keys Exchange uses to perform these actions, as well as
detail on how they are generated and populated in the Exchange Directory.
This security option provides for a completely opaque message
body (and signature). It generates a one time symmetric key and encrypts it in
the recipient’s public key, so that only that key owner can decrypt it, then
sends the message. On the recipient end, the private key is used to decrypt the
symmetric key which is then used to decrypt the message. This process is
transparent to the user. It is performed with no interaction between client and
additional network services except for a directory query to obtain the
recipient’s public key. The process is diagrammed as follows:
Figure 1: Message encryption/decryption process
When a digital signature is added to a
message, the message contents are used to compute a hash value that identifies
the sender and serves as a “digital fingerprint” that verifies the message has
not been altered in transit. A message digest algorithm, the message contents
and the sender’s private key are used to generate the hash value. The recipient
decrypts the original hash value with the sender public key, which is readily
obtainable from a trusted directory, such as the Exchange directory, or may
optionally be sent with the signed message. The message is decrypted, then a
new hash value is computed from the received text and compared to original hash
value. If they match, the contents and the sender’s identity are verified. The
entire process is diagrammed as follows:
Figure 2: Digital
signature process
Exchange uses several components to
secure items:
Exchange
Administrator—manages the
Advanced Security operations for an organization, including issuance and
revocation of certificates, recovery of certificates, setting of site
encryption algorithm preferences.
Archive database—stores keys/certificates
Directory—stores certificates/preferences for
client encryption and signing. For example, clients state in the directory the
maximum strength security that they support. 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, from the directory, other users’ certificates, performs all
cryptography on mail messages, and protects private keys in a secure
store
The Exchange Administrator program allows
you to control Key Management Server functions through objects—a CA object at the site configuration level, and additional property
tabs on recipients in the organization. The CA object shows up this way in the
Exchange Administrator:
Figure 3: Exchange Administrator CA Object
The recipient security tab (which appears
when the recipient’s properties are displayed) allows you to enroll, revoke,
and recover the recipient’s keys.
Figure 4: Security Tab 
Additionally a number of
administrator enhancements were added to the 5.5 release of Exchange, including
multiple password policies (missile-silo), automated token distribution via
e-mail, and bulk enrollment by recipient container.
Figure 5: Multiple Passwords Tab
The administrator can enable advanced
security per user or per recipient container. Enrolled users are sent a message
containing a token that they use to generate the signing key pair. If the
administrator transfers the token through email, users receive this enrollment
message:.
When enrolling users in Advanced
Security, the administrator must choose a certificate type: Exchange Server
version 4.0 through 5.5 support X.509v1 certificates, and Exchange 5.5 Service
Pack 1 extends support for X.509v3 certificates. Both X.509v1 and X.509v3
certificates can be issued to ensure backward compatibility. If 5.5SP1 is installed, the administrator can elect to change the
preferred certificate type and is then required to provide the name of the
Certificate Server for the organization. Since Exchange 5.5SP1 supports S/MIME
clients, the administrator must also choose preferred secure message
format—either Exchange 4.0/5.0 format (X.509v1 certificates) or S/MIME format
(X.509v3 certificates).
Figure 6:
Administrator prompt for providing a user with a new key
The token is used with a temporary
password and the permanent password to generate a 1024-bit key pair which is
then encrypted with the permanent password that the client supplied, and sent
to the System Attendant service. It sends the new key pair to the Key
Management Server, which sends it to the Cryptography Service Provider (CSP),
which generates the encrypting key pair, archives the private data encryption
key, and returns the data encryption key pair to the KMS. The KMS gets a public
key certificate for the new pair from the Certificate Server (CS) then archives
it.
Next, the KMS requests a signing key
certificate from the CS, receives it, then stores it in the archive database.
The KMS sends the signing public key certificate, the encryption public key
certificate, the encrypted private data encryption key, and the CA’s signing
certificate to the System Attendant, which assembles these into a single
message to the client.
The client creates a “user”.epf file
(where “user” is the alias that the user is currently logged in under, this
file contains the user’s certificates and private keys, encrypted with the
user’s permanent KMS password) then publishes the two certificates (for public
signing and encrypting keys) in the Exchange Directory. If the client accepts
other certificates, they are added to the user’s .epf file. The entire
enrollment process is detailed in Figure 6.
Figure 6: Client enrollment process
A certificate system must allow
administrators to revoke or expire user certificates, because users leave the
organization, working relationships with units or other organizations change,
etc. All certificates generated by Exchange Server must be renewed every year
(default). Administrators can renew them forcibly at any time. The renewal
process has five steps.
Client sends
a certificate renewal request to the System Attendant, which forwards it to
KMS. (Requests are sent to the SA automatically during enrollment in Advanced
Security, the client does not have to address them.)
KMS creates a new data encryption key pair, gets a
certificate for the newly generated public key from the Certificate Server, and
returns the new key pair to the client via the System Attendant.
Client creates a new signing key pair, then sends the new
signing public key to KMS via the System Attendant. KMS gets a certificate for the new signing public key from
Certificate Server and returns it to client via the System Attendant).
Client adds the new signing and encrypting certificates and
keys to its .epf file, and KMS adds the new security information to the key
recovery database.
The client publishes the new certificates
in the Exchange Directory.
When users lose keys or forget passwords,
they need KMS for key recovery KMS can recover an encryption key pair so that
previously encrypted items can be accessed. Signing keys are treated
differently—no one ever needs to forge an identity on a mail item, and only
users with valid private keys can send signed items. When the client generates
a new key pair, the new public key is placed in the directory in place of the
previous one.
Note that in the 5.5SP1 release of
Exchange, Certificate Server becomes the Certificate Authority (CA) for KMS,
which allows KMS to provide key-recovery for Certificate Server. This requires
that each Exchange KM Server must point to a Certificate Server (CS). Multiple
KM Servers within an organization can point to the same CS, but if it is not on
same machine you must install the CS client on the KM Server.
There are a couple of things to watch out
for. First, CS hierarchies will not be supported until Windows NT 5, so there
can be no subordinate trust relationships between CSs . Second, once a KMS
points to a CS, it cannot point to a new one, without invalidating the root of trust, and causing all mail encrypted
with certificates issued from this root to be inaccessible.
Don’t confuse moving a KM Server with
moving clients from one KM Server to another. If you move an entire KM Server
to a new machine, no clients are detached from their archived keys. To move a
KM Server, execute these steps:
Stop the
System Attendant on the machine running KM Server.
Backup the
Jet key archive database.
Restart the
System Attendant.
Run Exchange
Setup to remove the KM Server component.
Run Exchange
Setup on the new machine and install the KM Server component.
Copy the old
Jet database over the newly created empty database.
To revoke keys, administrators mark
certificates for individual users or entire organizations as no longer usable.
This is made relatively easy by the Certificate Revocation List (CRL), which is
stored in the Exchange Directory. It lists all revoked certificates, and is
signed by the KMS (the CA for the organization). Every time a client logs on to
check mail the CTL is checked to verify signatures on received mail.
Version 4.0/5.0 of Exchange Key
Management Server allows for recovery of users’ archived data encryption keys.
Version 5.0 and earlier of KMS store keys in encrypted text files (one file for
each user) on the KM Server. With the 5.5 release of Exchange, a new KM Server
utility transfers the keys to an archive database by going through the user key
files serially and transferring them to the new database format.
A user can have multiple entries in the
new database, each entry representing a layer of certificate history. If old
certificates are not maintained, users cannot decrypt old encrypted mail. Each
record in the database contains up to four certificates, and related state
information and certificate data
(serial number, expiration date, etc.). Stored certificates include two data
encryption certificates (an X.509v1 certificate generated by KMS and an X.509v3
certificate generated by MS Certificate Server) and two signing certificates
(one for each v1 and v3).
If administrators turn off Exchange
4.0/5.0 backward compatibility, newly generated records will not contain either
of the X.509v1 certificates. The signing certificate and the encryption
certificate differ only in that the encryption private key is encrypted and
archived, and the signing private key is generated once and never leaves the
client’s computer.
Finally, the archive database contains a
two-field record for each KMS administrator—security ID (SID) and password.
When an administrator’s privileges are revoked, the corresponding SID and
password are deleted from the database.
Public information is stored in and
retrieved from the Exchange directory. The directory also contains KM Server
information clients need to use advanced security:
X.509v1 and v3 public signing and data encryption
certificates for each enrolled user. Publication of these certificates allows
clients to look each other up in the Directory (rather than exchange keys
manually).
Exchange 5.5 SP1 allows you to store cross certificates of
other certifying authorities in the directory. Publication of these
certificates allows clients to authenticate and trust the root certificate of
external organizations and other Certifying Authorities (CAs) within their
organization. For instance, if Microsoft and Company A both use the same CA,
the establishment of a trust between Microsoft and Company A would be
facilitated because initial identity negotiation would not be necessary: both
organizations are automatically valid.
Certificate Revocation Lists (CRLs) for both the home
organization and cross-certified organizations. CRLs must be public in the
Directory so clients can determine if a message should be trusted.
Enrolled clients can send/receive signed
mail, receive encrypted mail, send encrypted mail to enrolled recipients, and
have KMS administrators recover their private key history. Clients generating
secured and signed messages perform all cryptographic operations with local
private, public, and public keys derived from the Exchange directory. Once
enrollment has concluded for generating secure or signed messages, no traffic
is generated between client and Key Management Server.
If you send a message to several users,
the symmetric key for message encryption or item signing is generated at the
lowest level common to the recipients (value queried from the Directory).
Symmetric keys are generated to send a message and used only once. If someone
derives a symmetric key by attacking a message, it is good only for that
message.
The newly released Outlook98 provides a
fully interoperable S/MIME client, uses standard X509v3 certificates, and
supports the Exchange 4.0/5.0 format for backward compatibility. Outlook
Express cannot address a KMS, so it obtains X.509v3 certificates from another
CA and therefore does not support Exchange 4.0/5.0 format secured messages.
Each time a client connects, Exchange reads the CRL from the directory to
verify signatures.
Exchange 5.5 has a Cryptography Service
Provider (CSP) that isolates all KMS cryptography functions into one dynamic
link library (DLL). This isolation allows the addition of new encryption
algorithms as they are developed, without having to wait for an Exchange KMS revision.
Exchange versions through 5.5 allow only
one KM Server per organization. Multiple-site architectures must configure
individual sites to point to one KM Server. Exchange 5.5SP1 KMS supports
Certificate Trusts Lists (CTLs), which allow cross-certification between
organizations and up to one KM Servers per Exchange site. CTLs contain
certificates from other trusted CAs (even those outside the Exchange
architecture), are signed by the root CA for the Exchange organization, and are
stored in the Exchange Directory. CTLs allows inter- and intra-organization
webs-of-trust which clients can use to validiate certificates attached
associated with received items. Should the need arise, administrators can
easily revoke trust for CTL certificates.
MS Certificate Servers also become
Certifying Authorities (CA) for Exchange 5.5SP1 KM Servers, and the ability to
have multiple KM Servers per organization does have caveats. One issue is
preservation of user histories (old encryption keys). If a site is modified to
point at a new KMS, user key histories are lost. To minimize such loss, you
should create new KM Servers only when you create new sites. Upgrade
considerations are outlined in the next section.
Networking KM Servers is complex and
risky, so configure them with care. Here are some example topologies:
Single upgraded KM
Server per organization—4.0/5.0
customers upgrade and do not install additional servers. No changes in
topology. All sites still point to this single KM Server. One MS CS is set up
and the single KM Server points to it. No risk.
Single upgraded KM
Server plus installation of additional servers—After the upgrade, a KM Server is added for the site named
Special-site. All special-site users now point to (and must be enrolled in
Advanced Security for) a new KM Server. Since archive databases are unique to
each KM Server, Special-site users can no longer recover keys from their old KM
Server and may not be able to recover mail encrypted that used the old keys. In
addition, the KM Server administrators may choose to set up either one MS CS
for all KM Servers to point to, or up to one MS CS for each KM Server. KM
Servers pointing to different CSs will need to cross certify each other.
Clean installation
of multiple KM Servers
(no upgrade)—If multiple KM Servers
are set up cleanly (no upgrade), users cannot lose the ability to recover their
key history: no databases have been established so there is no history to lose.
As above, KM Servers pointing to different CSs must cross-certify each other.
Administrators who move users to a new KM
Server should encourage them to protect their mail. Have them use a bulk
decryption tool (such as Sectool, in the Back Office Resource Kit) to decrypt
all their mail, move to the new KM Server, then re-encrypt with the new
recoverable key.
When deploying Advanced Security for an
organization, first determine the organization topology. Locate the KM Server
in a secure but accessible spot. Location becomes more important when you
deploy 5.5SP1 with multiple CSs and KM Servers. A smart placement plan for CSs
and KM Servers can simplify backup and recovery of KM databases and the key
issuance policies.
Next deploy the Exchange servers. If you
intend to support S/MIME clients, at
least one 5.5SP1 server must be deployed. Note that since 5.5SP1 uses
Certificate Server to generate public and private keys and certificates, there
must be CSs already deployed in the architecture. When deployment is complete,
you can decide the client functionality. If you want to deploy S/MIME clients,
you should deploy Outlook 98. If you want to sign and secure items within the
organization and are not concerned about compliance with S/MIME standards, you
can deploy any of the Outlook or Exchange clients.
Exchange 5.5SP1 provides a new
server-side feature that gives non-S/MIME clients two options for handling
S/MIME signatures: Preserve and Toss. “Preserve S/MIME signature” 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” removes
the signature associated with the message. Using this method, S/MIME clients
lose ability to verify signatures on messages, but all clients get readable
text.
When the supporting architecture is in
place, you can set up a trust network with external organizations.
First step, decide which external
organizations or CAs your organization should trust, then obtain their X509v3
root certificates. Conduct this crucial transfer out-of-band. With the CAs in
hand, you can populate the CTL property page, which directories access to
verify certificates. Note that this process is 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.
Exchange Server offers several options
for secure transmission, digital signature, and digital encryption. There are
three types of connections available:
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
All of these are possible through the
implementation of the previously discussed network and message security
options, and are listed as a practical implementation framework.
Exchange version 5.5 supports
authentication of SMTP delivery between servers in three ways: a combination of
SASL and AUTH, a combination of SASL/AUTH over SSL, or via Windows NT
Challenge/Response and NTRPC.
SASL provides a simple base level of
authentication and optionally allows two communicating hosts to negotiate a
security protocol. Exchange 5.5 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. When combined with SSL, these authentication and session security techniques
provide an encrypted and authenticated connection between the transfer hosts
for the “clear” SMTP transfer.
NT Challenge/Response is an encrypted
authentication protocol used between NT servers. If NTRPC encryption is turned
on (default between servers) the communication stream between the NT servers is
encrypted with 128-bit strength RC-4. This means that the SMTP mail transfer is
encrypted, even though the underlying SMTP transfer format is clear text. The
items are secure while being transferred over the Internet and only “clear”
after they have been received by the authenticated destination server.
Exchange versions 4.0, 5.0, and 5.5
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.
Exchange version 5.5SP1 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. After the certificates
are swapped, the users can send and verify messages that are digitally
encrypted, digitally signed or both.
Combinations of other techniques, these
options provide the highest available security: secure transmission,
individually secured or signed items, and non-repudiation and verification of
“opaque” content. These options are most efficient in small client populations.
These options require the presence of at
least one Exchange 5.5SP1 Server to generate X.509v3-compliant certificates and
to establish cross-certification between organizations.
CAST—a variable key length encryption algorithm developed by Carlisle
Adams and Stafford Tavares of Northern Telecom Research. This algorithm
supports keys 40 to 128 bits long.
Clear
item—a message that is readable when accessed
by..., that is not encrypted.
Data
Encryption Standard—(DES/Triple DES) an IBM
symmetric encryption block cipher which uses a fixed 56-bit key. It was defined
and endorsed by the U.S. government in 1977 as an official standard. Regarded
as the most widely used cryptosystem in the world. A process of encrypting
plain text three times with DES and three different potential series of
actions. DES-EEE3 (three DES encryptions with three different keys), DES-EDE3
(three DES operations in the sequence encrypt-decrypt-encrypt
with three different keys), or DES-EEE2 and DES-EDE2 (same as the previous
formats except that the first and third operations use the same key).
MD
(Message Digest Algorithm, MD4, MD5)—developed by
Rivest, this takes a message of arbitrary length and produces a 128-bit message
digest. The algorithm is optimized for 32-bit machines. Description and source
code for MD4 and MD5 can be found as Internet RFCs 1319 – 1321.
Opaque
item—message text that cannot be read without being
deciphered, also known as an encrypted item
RC2—a variable key-size block cipher designed by Rivest for RSA Data
Security. “RC” stands for “Ron’s Code” or “Rivest’s Cipher.” Faster than DES
and is designed as a “drop-in” replacement for DES. Because of the variable key size it can be made more secure or
less secure than DES against exhaustive key search. The algorithm is confidential and proprietary to RSA Data
Security.
RC4—a variable key-size stream cipher with byte-oriented operations
designed by Rivest for RSA Data Security.
SASL—Simple Authentication and Security Layer. Defined in RFC2222.
Secure
Hash Algorithm version 1—Published in 1994 as a
federal information-processing standard (FIPS PUB 180), this was developed by
NIST. Similar to the MD4 family of hash functions, this takes a message
of less than 264 bits and produces a 160-bit message digest. It is
slightly slower than MD5 but is more secure against brute-force collision and
inversion attacks.
SSL—version 3.0 is defined in the Internet draft <draft-ietf-tls-ssl-version3-00.txt>.
X.509—a standard released by the International Telecommunications Union
that specifies the formatting of a mechanism to verify public keys issued to
security principals in an organization.
Much of the basic security and algorithm
information was obtained from the RSA Corporation, Cryptography FAQ version
3.0. This FAQ is available on the web, from www.rsa.com.
Special thanks to MCS New Jersey’s Joseph
Pagano (Managing Consultant) and John Gomez (Consultant) for their assistance
with this chapter.
Q177492 XADM: Key Management Server
Fails to Reissue Key
Q148432 XADM: Location of the Key
Management Server Software
Q177309 XADM: Setup Cannot Initialize
the Key Management Database
Q177734 XADM: KM Server Features Not
Supported in Exchange 5.5 release
Q176737 XADM: Key Management Server
Fails to Start and Logs Event 5060
Q174743 XADM: Cannot Install 4.0/5/0
KMS After Installing 5.5 Server
Q156713 XADM: KM Server Stops
Intermittently on Alpha Servers
Q154531 XADM: Moving the KM Server to Another
Server in the Site
Q153394 XADM: Error When Selecting
Security Tab for Mailbox
Q152849 XADM: How to Recover from a
Lost Key Management Server
Q151689 XADM: Error Starting Key
Management Server
Q149333 XADM: The Basics of Advanced
Security
Q152498 XADM: Unable to Enable Advanced
Security on User Account
Q169519 XADM: Exchange 5.5 Remove All
Option Removes Database Files
Q146464 XCLN: Err Msg: Unable to Obtain
a Valid…Revocation List
Q1512686 XCLN: How Expired Encryption
Key Pairs Work
Q154089 XCLN: Cannot Send Sealed
Message when Offline
Q147421 XFOR: How Exchange Encryption
is Disabled on French Servers
Q176681 XGEN: Description of Microsoft
Exchange Server 5.5
Q146463 XGEN: KMS Cannot Write
Certificate Revocation List
Q143380 XGEN: Exchange Server Services
and Their Dependencies
Q170908 INFO: Key Management Server
Functions not Exposed to Developers
™
Exchange Advanced
Security and Its Implementation