Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

If you’ve ever looked at the Windows 2000 security model, you know that it is designed to provide security at the IP level, the application level, and just about everywhere in between. The mechanisms responsible for providing security work together to provide one tight security model. In this article, I’ll introduce you to some of the various Windows 2000 security-enabled protocols.

E-mail security

The first security enhancement that I’d like to discuss is called S/MIME. S/MIME is included in Outlook Express and Outlook 2000, and it’s an extension of the MIME message content format that you may already be familiar with. S/MIME is based on a new standard called Public Key Cryptography Standards (PKCS) #7. The PKCS #7 standard allows messages to be encrypted and digitally signed. Because of the way that S/MIME works, you can add several layers of security to a single e-mail message. For example, you can sign and then encrypt a message, or you can use an S/MIME nesting algorithm to sign the same message multiple times.

Signed messages

As I mentioned earlier, the PKCS #7 standard offers a method of digitally signing messages. Using PKCS #7, the signature is appended to the original message along with some other information. This information may include the signature algorithm and other information about the signer, such as their certificate or certificate chain.

Encrypted messages

The PKCS #7 standard also supports encryption of messages. Currently, this means using a combination of public key and symmetric key encryption. Public key encryptions tend to be secure, but very slow. To compensate for this fact, PKCS #7 encrypts the message using symmetric key encryption, which tends to be much faster than public key encryption. The down side to symmetric key encryption is that the key must be sent along with the message. To prevent anyone from stealing the key and decrypting the message, the symmetric key is encrypted using a public key algorithm. Because the symmetric key is so small, little overhead is required to perform this second level of encryption. When an end user receives the encrypted message, he uses his public key to decrypt the symmetric encryption key. Once this key has been decrypted, it can be used to decrypt the actual message.

Kerberos version 5

The various digital signatures and encryption algorithms are great for e-mail. But let’s face it–by themselves, they just aren’t enough. Not all communication between PCs occurs through e-mail. Just as often, confidential information is stored on network servers in the form of databases or other confidential files. Needless to say, such resources require a strong level of protection. Kerberos version 5 offers such a level of protection. It does this by using a combination of identification tickets to guarantee that your network clients really are who they claim to be.

Kerberos accomplishes this task by using a key distribution center and a ticket granting service. When a client logs on, he authenticates to the key distribution center through the use of a password, smart card, or other positive identification device. Once the client has authenticated into the key distribution center, he receives a special packet known as a ticket getting ticket.

Once the user has the ticket getting ticket, he is free to try to access the necessary resources. Now, let’s suppose that a client attempts to access a protected resource on a server. The resource requires a specific ticket for access. To get such a ticket, the client must go through a ticket getting service, which looks at the ticket getting ticket to confirm the identity of the client. If the client is allowed to access the specified resource, the ticket getting service will issue the user a service ticket, which can be used to access the resource in question. Now, the client attempts to access the protected resource for a second time. This time, when the server requests a ticket, the ticket the client just acquired is presented. To make sure the ticket is valid, the protected resource will send the client an encrypted packet. The client will then use the contents of the ticket to decrypt the packet. When the client decrypts the packet and issues a valid response to the server, access is granted.

Secure Socket Layer

So far, I’ve discussed how Windows 2000 can protect mail messages and server resources through various means. However, you may wonder what’s stopping someone from simply stealing packets as they flow across the network. You can prevent such a feat through the use of secure socket layers.

Secure socket layers (SSLs) are designed to provide a secure channel across an insecure medium such as a corporate network or the Internet. And SSLs can be used to add security to otherwise insecure protocols such as HTTP or Telnet.

The process begins by a client issuing a request to the server for a secure channel. When the server receives the request, it responds by issuing its public key certificate. The server can also be configured to require the client to issue a certificate as well, so the server knows which client it’s dealing with. You’d probably want to require client certificates in situations in which you’re dealing with computers that all belong to the company. However, it’s impractical to require a client certificate for anonymous access to a public Web server.

The next part of the process is verification of the certificates. Once the certificates are confirmed, the client will produce an encrypted session key that contains the server’s public key in its certificate. From this point until the end of the session, all communications between the client and the server are encrypted and decrypted by using the session key.

As you can see, Windows 2000 contains a variety of security mechanisms and protocols. Although no one security feature is comprehensive enough to protect Windows, all of the features that I’ve discussed work to provide a secure network operating environment. //

CrossLinks

• EarthWeb IT Management: “Security in Microsoft’s new enterprise OS”
• Microsoft: Code signing and PKCS #7
• Microsoft Windows 2000 Security Services site
• RSA Laboratories: “PKCS #7 – Cryptographic Message Syntax Standard”

Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the Director of Information Systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it’s impossible for him to respond to every message, although he does read them all.