Security-Enabled Protocols

Security in Windows 2000 exists at different levels—from the protection of entire messages at the application level, to secure channels, to the protection of data packets within IP. The security protocols residing at these different layers provide mechanisms not available at other layers.

S/MIME, for example, provides public-key-based encryption, integrity, and authentication of e-mail messages at the application level. SSL resides beneath the application layer, adding security to application protocols. IPSec, on the other hand, provides application-independent data protection at the IP layer. The following sections examine Windows 2000 security protocols.

Secure Multipurpose Internet Mail Extensions

S/MIME is included with Microsoft Outlook and Outlook Express. It uses private-key certificates to secure e-mail messages and files in accordance with the PKCS #7 standard. It supports both encryption and digital signatures. By nesting single S/MIME contents, messages can also be signed and then encrypted, or signed multiple times.

Signed Messages

A PKCS #7 digitally signed message includes the message signature, the signature algorithm, and information about the signer. Optionally, the signer's certificate or certificate chain can be added, as well as any CRLs that the verifier might need. Authenticated attributes, which are protected by the digital signature, and unauthenticated attributes can also be added to the PKCS #7 content. The time at which a message is signed is an example of an authenticated attribute.

The content that is signed might or might not be included in the PKCS #7 message. If the content isn't included, the verifier needs both the PKCS #7 content and the original file that was signed to complete the verification. If the original file is easily available, this method saves the overhead of having redundant data.

Encrypted Messages

The current PKCS #7 standard requires the use of two algorithms for message encryption. Because public-key algorithms are slow, the message is first encrypted with a symmetric-key algorithm, such as DES. The small symmetric key is then encrypted to the recipient, using a public-key algorithm, such as RSA. In this way, a message can be encrypted to multiple recipients while the actual content has to be encrypted only once.

The PKCS #7 message includes the encrypted content and symmetric-key algorithm along with information for each recipient. This information contains the symmetric key encrypted to that specific recipient. On receipt, an application searches the list of recipients for one that matches the current user's certificate. It then decrypts the symmetric key with the user's private key and subsequently decrypts the message.

Other Content Types

The degenerate case of the PKCS #7 message allows for the absence of the content and any signature information. This format provides a transport for certificates and CRLs. Table 18-5 shows the typical file extensions for different PKCS #7 files.

Table 18-5. Common PKCS #7 file extensions

Extension	Description
.P7M	PKCS #7 encrypted file or signed file with content added
.P7B	PKCS #7 file extension
.P7S	PKCS #7 signature file (signed file without the content)
.P7C	PKCS #7 certificate or CRL-only file

Kerberos Version 5

Kerberos is another authentication security protocol used by Windows 2000. It is used over a nonsecure network to mutually identify the requestor (user) and authenticator (network resource). Once identified, the user and network resource can encrypt transmissions to ensure privacy.

Kerberos works by issuing tickets to users for accessing resources on the network. Before exploring the high-level details of Kerberos, you need to understand some objects and services.

• Ticket A packet of data that allows a client to access a resource. It includes an encrypted piece of client information that, when decrypted, confirms identity.
• Ticket-granting ticket (TGT) A special ticket that allows the client to obtain temporary tickets from the ticket-granting service for each authentication.
• Key distribution center (KDC) A service that runs as part of Active Directory and administers TGTs.
• Ticket-granting service (TGS) A service that is accessed by a client with a TGT and that administers tickets for network resources.

The use of a ticket-granting service keeps the user from having to log on for each resource request. Figure 18-4 shows the details of a client using Kerberos to authenticate to a server. The steps are enumerated next.

Figure 18-4. A client using Kerberos to authenticate to a server.

1. A client authenticates once to the key distribution center by using a password or smart card.
2. The KDC issues a TGT to the client, for access to the TGS.
3. When the client wants to access a network resource, such as the corporate finance server, he or she requests a service ticket from the TGS, sending the TGT as proof of identity.
4. The TGS replies with a service ticket for use at the requested network resource server.
5. The client sends the service ticket to the network resource server for access.
6. To mutually authenticate, the network resource server replies with a packet that the client can decrypt.

Once a client completes the first two steps, steps 3 through 6 can be repeated each time a user needs to access another resource.

The advantage of this mechanism is that all Kerberos authentication occurs behind the scenes. The user needs to enter a password only once into the KDC—authentication to all other resources happens transparently.

Windows NT LAN Manager

Windows NT LAN Manager (NTLM) is the primary authentication mechanism for Windows NT 4. In Windows 2000, it is replaced by Kerberos as the default authentication protocol. NTLM is included as part of Windows 2000 for configurations that involve authentication between Windows NT and Windows 2000 machines.

Secure Socket Layer

Another Windows 2000 security protocol, Secure Socket Layer (SSL), uses public-key technology to provide a secure channel for applications communicating over a nonsecure network. A Web browser and Web server, for instance, could use SSL to communicate securely over the Internet. Before sending encrypted data, the client and server must engage in a security handshake to authenticate the parties involved and establish security levels. The handshake is a multipart process:

1. The client initiates connection with a request for a secure channel.
2. The server responds with its public-key certificate and can optionally request the client's certificate for mutual authentication.
3. The client verifies the server's certificate. If the server requested the client's certificate, the client sends it and the server verifies it.
4. The client generates and encrypts a session key with the server's public key found in its certificate.
5. All communication between the server and client is symmetrically encrypted and decrypted using the session key.

Figure 18-5 illustrates the SSL handshake process. In addition to authentication, the SSL handshake allows the two parties to agree on security parameters. Because of SSL's positioning, it can add security to application protocols such as HTTP, Telnet, FTP, Gopher, and NNTP.

Figure 18-5. The SSL handshake process.

Internet Protocol Security

Finally, the Windows 2000 IPSec security protocol provides end-to-end security of network data using encryption, digital signature, and hashing algorithms. The IPSec driver protects individual packets before they reach the network and unwraps the protection once they're received. Because the IPSec driver resides at the IP transport layer, individual applications don't need to handle the specifics of data security during transmission. Data passed though the network from security-ignorant applications can still be protected. Because IPSec protects the packets of data—not the actual link—IPSec can provide security for networkwide transmissions, and only the two computers engaging in communications need to know about it.

IPSec provides a number of security features:

• Authentication Use of a digital signature verifies the identity of the sender.
• Integrity Use of hash algorithms ensures that data hasn't been altered.
• Privacy Use of encryption protects data from being read.
• Anti-replay Prevents packets from being re-sent by an attacker to gain unauthorized access.
• Nonrepudiation Use of public-key digital signatures proves message origin.
• Dynamic rekeying Ability to generate keys during communication so that parts of transmissions are protected with different keys.
• Key generation Diffie-Hellman key agreement algorithm allows two computers to agree on a key without ever exposing it.
• Key lengths Provides configurable key lengths for export restrictions or highly sensitive transmissions.

IPSec Policy Management

An important component of IPSec is the policy agent. The policy agent begins during system startup and is responsible for retrieving IPSec policy information from either Active Directory or the registry and feeding it to the IPSec driver. For domain computers, the domain policy information is acquired from Active Directory at startup and at policy-defined retrieval intervals. For stand-alone systems or systems that are offline, the policy agent retrieves policies from the registry. When an offline machine reconnects, the retrieved domain policy overrides the local policy.

Figure 18-6 shows how policy information is transferred from Active Directory to the IPSec driver. The IPSec policy agent retrieves security policies and feeds them to the IPSec driver.

Figure 18-6. How policy information is transferred from Active Directory to the IPSec driver.

Chapter 19 describes how you can use IPSec Policy Management to define and manage IPSec policies for single computers or entire domains. Windows 2000 also provides predefined policies that can be customized to specific needs.

How IPSec Works

Before data can be protected and transmitted between two IPSec-enabled machines, a negotiation must take place to agree on which keys, mechanisms, and security policies to use to protect the data. This negotiation produces a security association (SA).

For IPSec communications, an initial SA called Internet Security Association and Key Management Protocol (ISAKMP) is established between the two computers to provide a method of key exchange. Using the ISAKMP for protection, a second negotiation takes place to produce a pair of IPSec SAs and keys, one for inbound and one for outbound communications. Specifically, these SAs include an agreed algorithm for encryption and integrity and the agreed IPSec protocol to use. The two IPSec protocols are:

• Authentication Header (AH) Provides data authentication, integrity, and anti-replay to IP packets
• Encapsulating Security Payload (ESP) Provides confidentiality along with data authentication, integrity, and anti-replay to IP packets

The IPSec SAs and keys are loaded into the IPSec driver on their respective machines and are used to protect data during transmission.