The Cable Guy - August 2006
AuthIP in Windows Vista
.gif "TechNet's The Cable Guy")
To simplify Internet Protocol security (IPsec) deployment, Microsoft® Windows Vista and Windows Server® 2008 support an enhanced version of the Internet Key Exchange (IKE) protocol known as Authenticated Internet Protocol (AuthIP). AuthIP provides simplified IPsec policy configuration and maintenance in many configurations and additional flexibility for IPsec peer authentication.
Introduction
Windows® XP and Windows Server 2003 support IPsec protection of traffic using built-in components that are integrated with the TCP/IP stack. To configure IPsec, you must configure and activate an IPsec policy, which can be done for individual computers or for an Active Directory® directory service container (a domain, site, or organizational unit) through a Group Policy object (GPO). Active Directory-based GPOs allow central configuration and automated distribution of IPsec policy to all domain member computers. An IPsec policy consists of general settings and one or more rules, which determine the types of traffic IPsec must examine, how traffic is treated (permitted, blocked, or protected), how to authenticate an IPsec peer, and other settings.
With the Server and Domain Isolation scenarios, more Microsoft customers are exploring the use of IPsec and deploying it on their networks. To correctly define the protected and unprotected sets of traffic on a network, network administrators must configure the appropriate IPsec policy settings. Although many Server and Domain Isolation deployments can use simple IPsec policy, more sophisticated deployments can require complex policy configurations that must be maintained over time. For example, administrators who want to implement Server or Domain Isolation might have to create a policy that contains a significant number of filters and rules to enforce isolation and to permit exceptions. For example, filters or rules might be required to specify the subnets to isolate, the services that are required by domain controllers and DNS servers, and so on.
Some of the complexity of IPsec policy for sophisticated Server and Domain Isolation scenarios is due to limitations in the IKE protocol and its implementation in Windows XP and Windows Server 2003. To reduce the complexity of IPsec policy configuration, even in sophisticated deployments, and to provide additional features for new scenarios, Windows Vista and Windows Server 2008 support AuthIP. AuthIP is a set of extensions to the existing IKE protocol with optional flags and extended negotiations that support increased security and deployability of IPsec. For backward compatibility with computers running Windows XP or Windows Server 2003, computers running Windows Vista or Windows Server 2008 support both IKE and AuthIP.
Features of AuthIP
The following are the features of AuthIP:
Performs user authentication
Performs authentication with multiple credentials
Provides improved authentication method negotiation
Performs asymmetric authentication
The following sections describe these features in detail.
User Authentication
Authentication for IKE in Windows XP and Windows Server 2003 is limited to the use of computer-based credentials; the Kerberos credentials of the logged in computer account, a computer certificate, or a preshared key. If you want to limit access to a server resource based on user credentials, the application must enforce user-level authentication and authorization. By limiting access at the IP layer to only authenticated users, the server being accessed is better protected because the application will only receive incoming requests from authenticated users.
AuthIP allows a user-level authentication that can be based on the following:
Kerberos credentials of the logged in user account
Windows NT/LAN Manager version 2 (NTLM v2) credentials of the logged in user account
A user certificate
A computer health certificate
Authentication with Multiple Credentials
The user authentication can be with or without an initial authentication based on computer credentials. For example, you can use Kerberos credentials to authenticate the computer and then a user certificate to authenticate the user of the computer. This ensures that only specific users and specific computers can initiate communication with a server containing sensitive information. With both computer and user authentication, the risk of attack by trusted computers is reduced.
Multiple credential support for computer health certificates is part of IPsec enforcement with the Network Access Protection platform, in which a health certificate is used to prove that an IPsec peer is both a member of the domain (using the Kerberos credentials of the logged in computer account) and compliant with system health requirements (using the health certificate). For more information about IPsec enforcement, see Internet Protocol Security Enforcement in the Network Access Protection Platform.
Improved Authentication Method Negotiation
IPsec peers might support two or more common methods to authenticate. With IKE, only a single authentication method is selected and tried. If the selected authentication method fails, IKE negotiation fails even though the alternate methods might have resulted in a successful authentication. For example, two IPsec peers in different Active Directory forests are configured to use both Kerberos (preferred) and certificate-based IKE authentication, but there is no trust between their forests. In this example, Kerberos authentication fails and therefore IKE authentication fails, even though both peers have certificates issued by a common trusted root certification authority.
With AuthIP, the alternate methods of user authentication are tried. When all of the possible methods of user authentication have failed, then IKE authentication fails.
Asymmetric Authentication
There are IPsec scenarios in which authentication requirements for the IPsec peers might be different, a situation known as asymmetric authentication. An example for the IPsec Secure Server scenario is when you have two IPsec peers that are communicating through a firewall from a perimeter network to an intranet. A one-way trust might exist between the perimeter network forest and the intranet forest. This allows intranet users to authenticate protected communications to computers in the perimeter network, but perimeter network users cannot authenticate protected communications to computers on the intranet.
Prior to AuthIP, this scenario can be done using complex certificate provisioning for computers on both networks to allow perimeter network users to authenticate protected communications to computers on the intranet. With AuthIP, the provisioning process can be simplified by configuring IPsec policy to require Kerberos authentication for communications initiated by intranet computers and certificate authentication for communications initiated by perimeter network computers.
Using IPsec Protection for Communication with a Domain Controller
In Windows Server 2003 and Windows XP, the current recommendation from Microsoft is to not use IPsec protection to protect traffic between a domain controller and a member computer (however, Microsoft does recommend protecting traffic between domain controllers). This is because the IPsec policy configuration can become very complex due to the different types of traffic sent between domain members and domain controllers. Additionally, if the domain controller requires IPsec-protected traffic from computers that must provide domain-based credentials for authentication, a computer that is not a member of the domain cannot contact a domain controller to join the domain.
As an example of the deployability enhancements made possible with AuthIP, Windows Vista and Windows Server 2008 support securing traffic between domain members and domain controllers in the following deployment modes:
You can configure IPsec policy in the domain to automatically determine when to use IPsec when communicating between domain members and domain controllers.
By enabling the new feature in IPsec for Windows Vista and Windows Server 2008 that automatically determines when to use IPsec, you no longer have to configure exemptions for domain controllers, simplifying IPsec policy and deployment of IPsec protection in a domain.
You can configure IPsec policy in the domain to request protected traffic but not require it.
Domain controllers will protect most traffic with domain members but allow clear text for domain joins and other types of traffic.
You can configure IPsec policy to require protected traffic for domain controllers.
To address the domain join problem, when a computer running Windows Vista or Windows Server 2008 attempts to join the domain, the user is prompted for the user name and password of a domain user account. IPsec with the domain controller is negotiated with NTLM v2 user credentials for a protected domain join. This new behavior is only available for computers running either Windows Vista or Windows Server 2008 and for domain controllers running Windows Server 2008.
For More Information
For more information about networking technologies in Windows Vista, consult the following resources:
For a list of all The Cable Guy articles, click here.