Lesson 1: Planning Authenticity and Integrity of Transmitted Data | MCSE Training Kit (Exam 70-220): Designing Microsoft Windows 2000 Network Security: Designing Microsoft(r) Windows(r) 2000 Network Security (IT-Training Kits)

A common security goal when designing application-level security is to prevent impersonation. Impersonation often involves an attacker who assumes the identity of a trusted individual on the network. Another form of impersonation is an unauthorized computer impersonating a trusted computer on the network. This lesson examines procedures implemented at the application layer to ensure the authenticity of all parties involved in a data transfer. These procedures also ensure that transmitted data isn't modified after being sent on the network.

After this lesson, you will be able to

Plan application layer methods that provide authenticity and integrity to transmitted data

Estimated lesson time: 45 minutes

Providing Authenticity and Integrity of Transmitted Data

A Windows 2000 network has two distinct methods for providing authenticity and integrity of transmitted data at the application layer. Server message block (SMB) signing can help ensure that file transmissions between a client and a server aren't modified in transit. For e-mail, both Secure/Multipurpose Internet Mail Extensions (S/MIME) and Pretty Good Privacy (PGP) provide the ability to digitally sign e-mail messages to protect them from being modified in transit.

Planning SMB Signing

SMB signing, also known as Common Internet File System (CIFS) signing, ensures the authenticity and integrity of packets transmitted between a client and a server. It does this by signing each packet as it's transmitted and verifying the signature at the recipient computer.

What Protections Does Signing Provide?

Signing is accomplished by running a mathematical algorithm over specific fields in a packet and arriving at a mathematical result. The recipient will run the same algorithm against the received packet and compare the results. If the results match, the packet's contents weren't modified during transmission.

WARNING
When SMB signing is implemented, the performance for transmitted data decreases. The overhead involved in signing and verifying each packet is roughly 10 to 15 percent more than when packets are transmitted without SMB signing.

SMB signing is negotiated between the client and the server when the initial SMB session is established, as shown in Figure 11.2. The process involves the following steps:

click to view at full size.

Figure 11.2 The SMB signing process

The client attempts to connect to a server that's configured to require SMB signing.
The server sends a challenge to the client. The challenge is the data that the client will encrypt to authenticate with the server.
The client responds by encrypting the challenge with a 168-bit session key computed from the user's password. The response and the algorithm used to encrypt the challenge is returned to the server.
The server validates the authentication attempt by performing the same algorithm on the challenge using the stored value of the user's password and comparing the results. If the results are the same, the user is authenticated.
The client and server negotiate which variation, or construct, of SMBs will be used by the client and the server. Which versions of SMBs are selected depends on the operating systems involved in the client/server exchange. The client and server always select the highest variation supported by both client and server.
Subsequent data exchange between the client and the server is protected by computing a digest for each message and including the digest with the message. The digest covers both the message text and the sequence number of the packet to ensure that a replay attack can't take place.

The key used to create the digests is created using the Message Digest v5 (MD5) algorithm. The MD5 message digest algorithm breaks the data into 512-bit blocks and produces a 128-bit message digest for each 512-bit block of the data. The key is computed from the session key established between the client and the server and the initial response sent by the client to the server's challenge.

SMB signing is commonly implemented in high-security networks to prevent impersonation of clients and servers. SMB signing authenticates the user and the server hosting the data. If either side fails the authentication, data transmission won't take place.

Consider using SMB signing in networks that implement both Windows 2000–based clients and down-level Windows clients. Internet Protocol Security (IPSec) Authentication Headers (AH) are supported only in pure Windows 2000 networks. SMB signing is supported by Windows 2000, Windows NT 4.0 (with SP3 or higher), and Windows 98–based clients.

NOTE
For information on deploying IPSec to provide authenticity and integrity of transmitted data, see Chapter 12, "Securing Data with Internet Protocol Security(IPSec)."

Planning the Deployment of SMB Signing

SMB signing requires modification of the registry in Windows 2000, Windows NT 4.0 (SP3 or higher), and Windows 98. The method used to deploy the registry depends on the operating system.

Deploying SMB Signing for Windows 2000–based Clients

In a Windows 2000 environment, which method you use to deploy SMB signing depends on whether the Windows 2000–based computers are participating in a workgroup or domain environment. In a workgroup environment, you deploy the security template file by using the Secedit command. In a domain environment, you can store the required modifications in a security template file and then deploy them by using Group Policy.

NOTE
For more information on deploying security templates in workgroup and domain environments, see Chapter 8, "Securing Microsoft Windows 2000–Based Computers."

When you configure a security template to use SMB signing, you can enable four separate options to tailor the SMB signing options to meet your organization's security requirements, as shown in Figure 11.3.

click to view at full size.

Figure 11.3 Configuring a security template to implement SMB signing

Digitally Sign Client Communications (Always). When enabled, this security option requires the Windows 2000–based computer to always use SMB signing when acting as the client in a Windows 2000 file session.
Digitally Sign Client Communications (When Possible). When enabled, this security option configures the Windows 2000–based computer to request the use of SMB signing when acting as the client in a Windows 2000 file session.
Digitally Sign Server Communications (Always). When enabled, this security option requires the Windows 2000–based computer to always use SMB signing when acting as a server in a Windows 2000 file session.
Digitally Sign Server Communications (When Possible). When enabled, this security option configures the Windows 2000–based computer to request the use of SMB signing when acting as the server in a Windows 2000 file session.

The choice of settings depends on the role that the Windows 2000–based computer plays on the network and the security requirements for SMB signing defined for your network.

In a domain environment you can import the security template to a specific domain, site, or OU Group Policy object. For example, you might want to require SMB signing when communicating with a specific group of servers hosting data for a sensitive project in your organization. You can create an OU for the servers, place all of the servers within the OU, and then import a security template that enables the Digitally Sign Server Communications (Always) security option, as illustrated in Figure 11.4.

click to view at full size.

Figure 11.4 Importing a security template enforcing SMB signing for servers to a specific OU

In a workgroup environment you must copy the completed security template locally to each Windows 2000–based computer that requires enabled SMB signing. The security template is then applied by creating a batch file that calls the Secedit command using the /configure option. For example, if the security template file were named Smbsign.inf, you could use the following batch file to apply the security template settings and store them in a database named Security.sdb:

 secedit /configure /DB Security.sdb /CFG Smbsign.inf /overwrite

Deploying SMB Signing for Windows NT 4.0–based Clients

Windows NT 4.0 introduced support for SMB signing in Service Pack 3. The ability to deploy SMB signing in Windows NT 4.0 requires editing the registry. To enable SMB signing in a Windows NT 4.0 environment, you must edit different registry values depending on whether the Windows NT 4.0–based client is acting as a client or a server.

If the Windows NT 4.0 client is functioning as a server, you must consider editing these two registry values to deploy SMB signing to match your organization's security requirements:

Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
\LanManServer\Parameters
- Value Name: EnableSecuritySignature
- Data Type: REG_DWORD
- Value: 0 (disable), 1 (enable)
- Default: 0 (disable)
Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
\LanManServer\Parameters
- Value Name: RequireSecuritySignature
- Data Type: REG_DWORD
- Value: 0 (disable), 1 (enable)
- Default: 0 (disable)

When the Windows NT 4.0 client is functioning as a client, you must edit two different registry values to meet your organization's security requirements:

Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
\Rdr\Parameters
- Value Name: EnableSecuritySignature
- Data Type: REG_DWORD
- Value: 0 (disable), 1 (enable)
- Default: 1 (enable)
Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
\Rdr\Parameters
- Value Name: RequireSecuritySignature
- Data Type: REG_DWORD
- Value: 0 (disable), 1 (enable)
- Default: 0 (disable)

You can deploy these settings by creating a custom template file and then applying them with the System Policy Editor. Assuming that the Windows NT 4.0 client is operating in a domain environment, you can apply the settings to a Ntconfig.pol configuration file. You can then place the modified Ntconfig.pol file in the Netlogon share to ensure that the settings are applied to all required clients.

NOTE
For more information on deploying SMB signing in a Windows NT 4.0 environment, see Knowledge Base article Q161372 on the Supplemental Course Materials CD-ROM (\chapt11\Q161372.mht).

Deploying SMB Signing for Windows 98–based Clients

Windows 98 also includes an updated version of the SMB protocol that allows Windows 98–based clients to participate in SMB signing. As with Windows NT 4.0–based clients, you enable SMB signing by editing the registry, but the registry keys are different.

You can enable SMB signing on Windows 98–based computers by configuring the following two registry values:

In HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
\VxD\Vnetsup
- Value Name: EnableSecuritySignature
- Data Type: REG_DWORD
- Value: 0 (disable), 1 (enable)
- Default: 1 (enable)
In HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
\VxD\Vnetsup
- Value Name: RequireSecuritySignature
- Data Type: REG_DWORD
- Value: 0 (disable), 1 (enable)
- Default: 0 (disable)

NOTE
Once you've completed the registry modifications, you need to reboot the Windows 98–based computer before the modified settings take effect.

For Windows 98–based computers, the easiest way to deploy this setting would be to e-mail a .reg file containing the desired settings to all Windows 98–based clients. Users import the settings at their computers by double-clicking the .reg file. You can use system policies only if the network has no Windows 95–based clients. Windows 95-based clients don't support SMB signing.

NOTE
For more information on deploying SMB signing in a Windows 98 environment, see Knowledge Base article Q230545 on the Supplemental Course Materials CD-ROM (\chapt11\Q230545.mht).

Making the Decision

You must consider the decision points in Table 11.2 when you develop a design for SMB signing on a network.

Table 11.2 Planning SMB Signing Security

To	Consider the Following
Require that all communications to a server require SMB signing	Configure the server to enable the use of SMB signing and also to require the use of SMB signing. Configure all required client computers to either enable or require SMB signing.
Allow SMB signing to take place but still allow fallback to unsigned communications	Configure the server to enable only SMB signing.
Deploy SMB signing configuration for Windows 2000–based clients	Create a security template that enables the required SMB signing configuration. Place all computers that require the settings into a common OU structure. Import the security template into a Group Policy object applied at the OU.
Deploy SMB signing configuration for Windows NT 4.0–based clients	Create a custom system policy template that contains the required SMB signing settings. Modify the Ntconfig.pol file to apply the required SMB settings. Ensure that all Windows NT 4.0–based clients have Service Pack 3 as the minimum service pack level.
Deploy SMB signing configuration for Windows 98–based clients	Create a .reg file that contains the required SMB settings for Windows 98–based computers. Distribute the .reg file to all Windows 98–based computers. Apply the .reg file to the Windows 98–based computers. Restart the Windows 98–based computers.

Applying the Decision

To meet the requirement to mutually authenticate clients and servers, you must implement SMB signing at the HELIOS server for the Radar System project. The offices involved in the Radar System project use a mix of Windows 98, Windows NT 4.0, and Windows 2000. As discussed in this chapter, all of these operating systems support the use of SMB signing to ensure mutual authentication of clients and servers.

To deploy SMB signing, you have to use different methods based on the computer's operating system. There are four possible systems:

The HELIOS server. You can place the Windows 2000–based server in an OU that has the Digitally Sign Server Communications (Always) security option enabled in Group Policy. This setting ensures that any clients that connect to the HELIOS server must use SMB signing. In addition, you must configure the share where the project files are stored with Share and NTFS permissions that give access only to authorized users.
Windows 2000 clients. The Windows 2000–based clients at each office can be placed in the same OU as the HELIOS server or in a sub-OU based on the Windows 2000 client's office location, as shown in Figure 11.5.

Figure 11.5 Proposed OU structure for Windows 2000–based clients for Fabrikam inc.

The Group Policy object (GPO) should be set so that the computers digitally sign client communications, but only when required. This setting allows the computers to still communicate with other servers in the organization that may not require SMB signing but use SMB signing when connecting to the HELIOS server. When you apply the GPO at a parent OU, the GPO is inherited by all child OUs by default.
Windows NT 4.0 clients. You can create a system policy template that enables the Windows NT 4.0–based clients to enable SMB signing. You can apply the template file to the file Ntconfig.pol stored in the Netlogon share of all domain controllers in the corp.fabrikam.tld domain. The Windows NT 4.0–based computers then apply the system policy every time they're restarted and they authenticate with the network. To ensure that the system policy setting works, all Windows NT 4.0 clients must be configured with at least Service Pack 3.
Windows 98 clients. You should create a .reg file that enables SMB signing for Windows 98 clients. Because Fabrikam uses a single-domain model and the domain has Windows 95 clients, you shouldn't deploy the registry setting for SMB signing by using system policy because the policy would also be applied to Windows 95–based computers. You could e-mail the .reg file to the Windows 98 users or apply it with a login script.

SMB signing isn't required for the Sonar System project. If the Sonar System project required integrity and authenticity of the data, an alternative method would be needed because the project involves Windows 95–based computers that don't support SMB signing.

Planning Digital Signing

While SMB signing protects file transmissions between a client and a server, digital signatures ensure authenticity and integrity of e-mail messages between clients.

Digital signatures differ from SMB signing in that a Public Key Infrastructure (PKI) is required to deploy the necessary public/private key pairs to participating clients. Once a participating client has acquired a private/public key pair, the client can implement digital signatures to protect e-mail messages.

Digital signatures ensure that the contents of e-mail messages aren't modified in transit. Additionally, the digital signature confirms that the message originated from the correct source. This feature works in two ways. First, it prevents someone from impersonating another e-mail user, and second, it prevents an e-mail user from denying that he sent a specific e-mail message.

Digital signatures function by applying a digest function to the contents of the message. The digest function creates a message digest as output. The message digest is a representation of the message. If the contents of the message are modified, the message digest output will also change. Both the sender and receiver of the message will run the same digest function against the e-mail message. The recipient's e-mail application will compare the two digests to determine if the contents have been modified. If the digests match, the contents haven't been modified.

NOTE
While it's theoretically possible to modify a message so that the message digest function returns the same value, it's highly improbable that this will happen.

Figure 11.6 shows the digital signature process that occurs when an e-mail client sends a digitally signed message to a recipient. The process involves the following steps:

click to view at full size.

Figure 11.6 Digital Signatures preventing modification of an e-mail message

The sender creates a plaintext e-mail message. By default, Post Office Protocol v3 (POP3)/Simple Mail Transfer Protocol (SMTP) e-mail clients send their messages in plaintext format.
The sender will run a known algorithm against the plaintext message to create a digest of the message. Most commonly, either a Secure Hash Algorithm v1 (SHA1) or MD5 algorithm is used to create the digest.
NOTE
SHA1 and MD5 are both algorithms that produce a message digest when applied against the contents of an e-mail message. SHA1 is considered to be slightly stronger than MD5 because the digest for SHA1 is 32 bits longer than the digest for MD5.
The digest is encrypted using the sender's private key. The digest is securely transmitted to the recipient and only the sender's public key can be used to decrypt the encrypted digest.
The plaintext message and the encrypted digest are sent to the recipient by using SMTP. For digital signing, no protection is applied to the plaintext message. The message can be modified, but modification will invalidate the encrypted digest sent with the message.
The recipient decrypts the encrypted digest by using the sender's public key. The public key is retrieved either from a directory where the public key is stored (such as Active Directory directory service) or is included in the signed message.
The recipient runs the same algorithm used by the sender to create the recipient's own digest of the message. This digest is created against the plaintext message received from the sender.
The two digests are compared. If the digests differ, the message was modified during transmission. If the digest can't be decrypted, the sender was masquerading as another user.

Determining Protocol Choices for Digital Signing

Two protocols currently provide digital signatures for e-mail applications:

Secure Multipurpose Internet Mail Extensions (S/MIME). An S/MIME extension provides the ability to encrypt and digitally sign e-mail messages by using public and private key pairs. The biggest benefit of implementing S/MIME is that S/MIME is an Internet Engineering Task Force (IETF) standard designed to extend the MIME standard to provide secure e-mail functions. S/MIME requires only that the e-mail applications support S/MIME. There's no requirement for the e-mail servers to support S/MIME.
Pretty Good Privacy (PGP). PGP is also a protocol that provides the ability to encrypt and digitally sign e-mail messages. As with S/MIME, PGP provides this ability by using private/public key pairs. The main difference with PGP is that PGP isn't controlled by a centralized standard organization.

The decision on which protocol to use is often based on the e-mail applications deployed for an organization.

IMPORTANT
While S/MIME and PGP provide the same functionality, they aren't interoperable. You can't send signed e-mail between e-mail applications that support different protocols. If you use S/MIME to sign a message, the recipient must also support S/MIME.

Deploying Public Keys

The main challenge that an organization faces when implementing digital signatures is ensuring the availability of public keys. Without a public key, the digest encrypted with the sender's private key can't be decrypted to verify message integrity.

To ensure the availability of public keys, do the following:

Configure e-mail clients to include their certificate with all signed messages. Including the certificate in the signed message ensures that the recipient has the public key required to decrypt the message digest. The public key associated with the digital certificate is included as an attribute of the digital certificate.

IMPORTANT
The digital certificate must be issued by a Certificate Authority (CA) that the recipient trusts. In addition, the certificate revocation list (CRL) must be accessible to any recipients so that the revocation status of the digital certificate can be verified. If the CRL can't be accessed, the certificate is assumed to be revoked.

Implement the Key Management Service (KMS) in Microsoft Exchange Server 5.5 or Exchange 2000 Server. The KMS service manages private/public key pairs and ensures that the public keys are stored within the directory (Exchange Server 5.5 users use the Exchange directory and Exchange 2000 Server users use the Active Directory for storage of public keys).

Making the Decision

Table 11.3 discusses the design decisions that you need to make when implementing digital signatures for e-mail messages.

Table 11.3 Planning Digital Signature Design

To	Do the Following
Choose which protocol to use for digitally signing e-mail messages within your organization	Determine which protocol is supported by your organization's e-mail application.
Ensure that important messages are digitally signed	Train users on how and when to digitally sign messages.
Ensure that digital signatures are validated	Configure e-mail applications to include the digital certificate in all signed messages. Ensure that the CRL publication point for all CAs is available to recipients.
Limit which users can use digital signatures	Deploy certificates that support digital signatures only to approved users.

Applying the Decision

Fabrikam must provide the ability to digitally sign messages for three scenarios:

Defense Department price quotes. All price quotes to the Defense Department must be digitally signed to ensure that the contents aren't modified during transmission. The digital signature will also prove that the e-mail originated from the validated user at Fabrikam. For this process, the public key of the e-mail sender must be available publicly to allow a recipient at the Defense Department to acquire the public key and verify that the certificate associated with the private/public key hasn't been revoked. Either the certificates must be acquired from a public CA, or the issuing CA's CRLs must be published externally. Because the e-mails are being sent to another organization and security is a key requirement, the recommendation would be to acquire the certificates for these transactions from a public CA such as RSA or Verisign.
The Radar System project. All e-mails regarding specifications must be digitally signed to ensure that the e-mail is from the correct source. Digitally signing the messages validate the sender of the specifications within the email. Because the transmissions are internal, you could use a private CA to issue the certificates required for the digitally signed e-mail.
The Sonar System project. E-mail exchanged between A. Datum Corporation and Fabrikam should be digitally signed to ensure the authenticity of the e-mail messages and to prevent changes to them. Fabrikam and A. Datum Corporation should either acquire certificates from a public CA or establish a cross certification between their two internal CA hierarchies to ensure that certificates from the other organization can be validated.

Fabrikam must determine which users need to acquire certificates for digitally signed e-mail. Based on requirements, only users involved with the three projects must acquire digital signatures. All the users at Fabrikam don't need to issue certificates for digitally signed e-mail.

Finally, for the digitally signed e-mail sent to outside organizations (the Defense Department and A. Datum Corporation), the network administrators must determine whether the partners use PGP or S/MIME for their e-mail packages. This decision determines which e-mail applications must be used at Fabrikam to ensure that the partner's e-mail application can validate the digital signatures.

Lesson Summary

The transmission of sensitive data such as contracts and ordering information across and between networks makes it necessary to verify that the original message hasn't been modified in transit and that the message originated from the true source. Implementing SMB signing in a network ensures that mutual authentication of client and server takes place and prevents an attacker from impersonating a client or server. Digital signatures ensure that the contents of e-mail messages aren't modified. Together, these two technologies help prevent attacks caused by someone impersonating an authorized user or computer.