Ask Us About... Security - December 15, 2001

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Steve Riley

On This Page

Building a Trusted Computing Infrastructure with IPSec AH
What Is a Trusted Computing Infrastructure?
How IPSec AH Makes It Possible
Building the TCI: Two Stances
Why It Works
More Information

Building a Trusted Computing Infrastructure with IPSec AH

When most people think about IPSec, it's encryption that comes to mind. And yes, that was and is the primary goal: guaranteeing that communications between Alice and Bob remain confidential and unmodified. But what if there's no need for encryption—can IPSec still do anything useful? Most definitely yes.

IPSec is really a pair of protocols, which operate somewhat differently on IP packets:

  • ESP, encapsulated security payload (IP protocol number 50). ESP encrypts the payload and certain parts of the header, providing for confidentiality and integrity of the data.

  • AH, authenticated header (IP protocol number 51). AH computes a checksum across the entire packet, ensuring integrity of both the data and the source/destination information.

There's plenty of good information on IPSec available from various sources. See the end of this column for a list. For now, we'll concentrate on using IPSec AH to build what I call a "trusted computing infrastructure."

What Is a Trusted Computing Infrastructure?

You know who your users are. You have a Microsoft Windows® 2000 Active Directory® directory service to which your users authenticate when they want to use network resources. But what about the computers? Sure, some of the computers are joined to the domain. The architecture of Windows doesn't require this, though. As long as a user possesses valid credentials, he or she can access network resources from any computer on the network.

Consider the following scenarios in which you might want to know the computers in use:

  • You have a policy that requires users to use only IT-built and authorized machines.

  • You want to force servers in your data center to communicate only with other data center servers built following a standard procedure—in other words, rogue servers in the data center shouldn't be allowed to communicate with other servers.

  • You want to limit server-to-server communications within your perimeter network (also known as DMZ, demilitarized zone, and screened subnet) ensuring that unknown computers can't pretend to be legitimate.

IPSec AH gives you the means to build such an infrastructure.

How IPSec AH Makes It Possible

IPSec has some characteristics that permit deploying a trusted computing infrastructure.

Packet authentication. AH authenticates—ensuring the integrity of—the entire IP and next protocol (TCP, UDP, or ICMP, for example) header, plus the packet's payload. A one-way hash of the packet provides a checksum. The initiator computes the checksum and attaches it to the packet before it sends it out; the responder computes the checksum when it receives the packet. If the computed checksum matches the attached checksum, the packet hasn't been modified during transmission. The one-way nature of the checksum means that it can't be altered in flight.

Controllable authentication methods. This is where the actual trust comes about. IPSec requires that any pair of machines involved in secure communications first authenticate themselves to each other. You can build an IPSec policy to use any of three methods: certificates, preshared keys, or Kerberos.

  • Certificates. This is the preferred method for a trusted computing infrastructure. As a domain or enterprise administrator, you can control the distribution of machine certificates from an internal Windows 2000 certificate authority. By controlling distribution, you can control which machines participate in IPSec AH policies, thus permitting machine-to-machine communication only between authenticated entities.

  • Preshared keys. Useful for testing policies, but vulnerable to compromise in production. Preshared keys are stored in the clear in the registry, and by their nature tend not to remain secret for very long.

  • Kerberos. When two Windows 2000 machines are in the same forest, IPSec can use Kerberos to perform automatic authentication. This is useful when domain users want to configure IPSec ESP between their own machines, but possibly less useful in trusted computing infrastructures. See the "Building the TCI: Two Stances" section below for more details.

Building the TCI: Two Stances

There are a couple different stances you can take as you plan your trusted computing infrastructure (TCI).

  • Every machine in your organization must have a certificate.

  • Only data center and perimeter network servers must have certificates.

The stances have varying implications and requirements.

An Enterprise-Wide TCI

Here you're essentially saying that no user can bring up a rogue machine and access domain resources. Access to resources can happen only from authorized machines that belong to the domain. If this is your preferred stance, then you can choose to use either certificate-based or Kerberos authentication for IPSec. Kerberos is easy to implement since it already exists; certificate-based authentication gives you greater flexibility if you want to have varying policies among different groups in your organization.

To deploy an enterprise-wide TCI using Kerberos for IPSec authentication, just add an IPSec policy to the default domain policy which:

  • Doesn't activate the default response rule

  • Doesn't specify a tunnel

  • Applies to all network connections

  • Uses Kerberos as the authentication method

  • Uses the existing "All IP Traffic" filter list

  • Uses a filter action that doesn't communicate with non-IPSec machines and has a custom security method with AH only (you'll have to create this; it isn't one of the predefined sample actions)

This stance prevents non-domain machines from communicating with any other machine. All domain members will receive the policy and will therefore be able to communicate with all other domain members. If you allow users to add and remove their own machines from your domain, you won't be able to control who does and who doesn't receive the policy. Note that this isn't necessarily a problem.

To deploy an enterprise-wide TCI using certificates for IPSec authentication:

  1. If you don't already have one, install a Windows 2000 certificate authority (see the end of the paper for pointers to more information).

  2. Configure your domain for automatic machine enrollment—each time a computer joins a domain it automatically receives a certificate; an existing domain machine without a certificate will receive one next time it boots.

  3. Add an IPSec policy to the default domain policy; configure the policy as above except that you should use certificates rather than Kerberos for authentication.

This looks just like the Kerberos situation: all domain members receive a certificate and the policy and will therefore be able to communicate with all other domain members.

Certificates can give you a little more flexibility, though. Consider the following example. You allow your users to add and remove their own computers from the domain. You generally aren't concerned with authenticating the machines of individual users; however, there's a certain group of servers to which you do want machine authentication. The traditional way to make this happen is with access lists based on IP addresses. There are two problems with this: you need to know the addresses of all potential clients; you can't do anything to prevent address spoofing. A better alternative is to eliminate reliance on addresses and instead require the client computers to assert some kind of identity. Machine certificates are ideal for this.

  1. Install a Windows 2000 certificate authority.

  2. Don't configure machine autoenrollment! Instead, configure the CA so that machine enrollment must be manually approved by an administrator.

  3. Create an organizational unit in Active Directory for the servers in question; add these servers to the OU. Enroll each of the servers with a machine certificate from the CA.

  4. Create a group policy that includes an IPSec policy requiring certificate authentication; add the group policy to the OU from the previous step. Carefully consider the filter list: in case the server should ever need to make a connection to a server that doesn't require authentication, you'll probably want to configure the filter list such that incoming traffic requires authentication but outgoing traffic doesn't.

  5. Manually enroll the machines of the users requiring access to these computers.

You've now set up these servers so that any machine that wants to communicate must first authenticate itself with IPSec AH. Since you're controlling enrollment, you can control which computers receive the appropriate certificate and therefore are permitted to communicate with the servers.

Trusting your certificate authority. While certificates give you flexibility, they also increase the amount of trust you need to have in your environment. Deploying a certificate-based TCI requires that your CA itself be a trusted, highly tamper-resistant computer. If you can't trust the root certificate authority, then you can't trust any of the certificates generated either by that CA or any subordinate CA. The PKI papers mentioned at the end of this document describe how to build and maintain trusted certificate authorities.

A Server-to-Server TCI

You're building a data center. You want to ensure that no rogue servers—whether installed in the data center or somewhere out on the Internet—can pretend to be legitimate members of the data center. By configuring a CA and IPSec AH as described here, you can create this kind of environment. This stance requires certificates and has the added benefit of protecting against address spoofing: regardless of what a machine claims its address is, if it doesn't have a certificate, it can't communicate; since you control enrollment, you control the communication.

To deploy a server-to-server TCI using certificates for IPSec authentication:

  1. If you don't already have one, install a Windows 2000 certificate authority (see the end of the paper for pointers to more information). If you already have a CA, you'll need to build another CA dedicated for this purpose. Configure the CA so that machine enrollment must be manually approved by an administrator.

  2. Create an organizational unit in Active Directory for the servers and add them to the OU. Enroll each of the servers with a certificate from the CA you just created.

  3. Create a group policy that includes an IPSec policy requiring certificate authentication. The filter list should limit the policy to the IP address range of the servers. This way, the policy isn't triggered when client machines access the server. To protect against the case in which an outside attacker spoofs an internal address, be sure that you're blocking such spoofed traffic at your border router: that is, block all inbound traffic with a source address of your internal network.

This stance is quite useful for communications between computers in a perimeter network and computers in the core network. Now you can know and trust that traffic between these computers is between only your computers and not with some attacker purporting to be a part of your perimeter network.

Why It Works

Recall that domain members can access network resources from any computer so long as they possess valid credentials. Compromised credentials could permit someone to remotely attack part of your network. By requiring the computers to authenticate themselves to each other, we eliminate this potential vulnerability.

That you can control the authentication process is what forms the trust. If your goal is simply to ensure that all network access is from domain member computers, then a forest-wide IPSec AH policy with Kerberos authentication is entirely appropriate. If you want to protect against the vagaries of IP address spoofing or rogue servers, requiring IPSec AH on all servers is the way to go.

More Information

Step-by-step guides explain how to configure the required services.

Detailed papers describe how the technology works.

Please send any feedback or questions regarding the content of this column to Microsoft TechNet.