Kerberos in Win2K

Does the new default authentication protocol's bite live up to its bark?

In Greek mythology, Kerberos is the three-headed dog that guards the entrance to the underworld. The latest Kerberos development is a little less ferocious. Request for Comments (RFC) 1510 defines the basic Kerberos protocol, which was developed at MIT as part of the Athena project and deals with user authentication. Microsoft embedded its version of Kerberos in Windows 2000 (Win2K) as the new OS's default authentication protocol. In this article, I discuss key features of Microsoft's Kerberos implementation.

The Basics
When two entities want to authenticate to each other (e.g., a user and a resource server), they need a trusted third party to mediate between them. In Win2K, the Kerberos Key Distribution Center (KDC) adds scalability to the Kerberos protocol and serves as the mediator, and every domain controller runs a KDC service. You install the KDC service during the Active Directory (AD) installation. AD contains a copy of users' credentials (i.e., a hash of users' passwords), which Kerberos uses in the authentication process.

Win2K includes a client Kerberos authentication provider and Kerberos support for other clients, such as Windows 9x. If you want your Win9x client to use Kerberos for authentication, you must install the Directory services client. If you want Microsoft Kerberos support for your Windows NT 4.0 workstation, you must upgrade to Win2K Professional (Win2K Pro).

Kerberos' Ticketing System
The core of the Kerberos protocol is a unique ticketing system that provides faster authentication than earlier NT versions. A Kerberos ticket provides a way to transport a Kerberos session key, which is the basic entity Kerberos uses for authentication, securely across the network. Kerberos authentication is based on symmetric key cryptography. For example, suppose Alice and Bob share a session key that they want to use for authentication. When Alice wants to authenticate to Bob, she uses the session key to encrypt her name and the current timestamp and sends the result to Bob. (Kerberos terminology calls this encrypted packet the authenticator.) Bob uses the session key, which only Alice and Bob know, to decrypt the packet. If the decryption results in Alice's name and an acceptable timestamp, Bob knows that only Alice could have sent the packet. Kerberos uses tickets to ensure that the session-key exchange is secure.

Kerberos generates all session keys in the KDC. The KDC also creates the associated tickets and sends them to the client and the resource server via the client. (The resource server is the machine hosting the resource that the user wants to access.) A ticket is an encrypted version of the session key that only the resource server and a Win2K domain controller can decrypt. The KDC sends all tickets via the client, so the client can cache tickets and reuse them. (The client stores tickets in a special system memory area that the system never pages to disk.) However, tickets have a limited renewal period and lifetime. During the renewal period, the KDC renews the ticket transparently. If the renewal period expires, users need to rerun the logon sequence.

When a resource server gets a ticket and an authenticator from the client, the server has enough information to authenticate the client. NT 4.0 requires the server to contact a domain controller to validate a user's authentication request, but thanks to Kerberos, Win2K doesn't require pass-through authentication. The ticketing system accelerates the authentication process, but it also puts a greater workload on the client.

Kerberos' ticketing system uses two basic ticket types: ticket-granting tickets (TGTs) and service or resource tickets. When a user uses his or her password (master keys in Kerberos terminology) to successfully log on to a Win2K domain, the domain controller's KDC service generates a TGT and sends it to the user. TGTs secure the transport of the session key that the KDC uses to authenticate the user. Kerberos' TGTs and the associated session key limit the use of users' passwords for authentication, reducing the possibility of brute-force attacks on packets encrypted with users' passwords. At logon and at each TGT renewal, users use their password to authenticate to the KDC. In subsequent ticket requests, users use their session key, which their TGT contains, to authenticate to the KDC. Consequently, if a user changes his or her password during a logon session, the user must reenter his or her user ID and password to obtain a new TGT.

To authenticate to a resource server, users need another session key. Kerberos uses a service or resource ticket to secure the transport of this session key. People use their cached TGT to obtain a service ticket from the KDC. When a user has a TGT and an authenticator, the KDC knows that the domain controller has already successfully authenticated the user, so the KDC permits the user to get a service ticket.

Win2K's software development kit (SDK) includes Klist, a tool that lets you view the Kerberos tickets that the local machine has cached and lists the tickets' properties, as Screen 1 shows. In addition, you can use a Win2K Group Policy Object (GPO) to set a user's TGT lifetime, service ticket lifetime, and maximum renewable period, as Screen 2 shows. The default settings are 30 days for a TGT, 29 days for a service ticket, and 60 days for renewal. Users' TGT lifetime settings need to be greater than their service ticket lifetime value, and the maximum renewable period settings need to be greater than the TGT and the service ticket lifetime values. In the same GPO folder, you can also set the maximum time skew that a resource server will tolerate between a ticket's timestamp and the time when the resource server receives the ticket. Kerberos uses timestamps to protect against replay attacks, so setting this value too high creates a greater risk for replay attacks.

Microsoft includes a user's Win2K authorization data in the authorization data field, which is part of every Kerberos ticket. Microsoft calls this field the Privilege Attribute Certificate (PAC). In Win2K, the KDC adds PAC data to a ticket, and subsequent TGT and service ticket requests and renewals inherit this data. However, the KDC doesn't refresh the PAC data when a user requests a new ticket. Thus, if a user's group memberships change during a logon session, the user must log on and log off to receive a new ticket.

Mutual Authentication
To validate a client's identity, NT 4.0 supports a challenge/response authentication sequence in which the server challenges the client, the client calculates a response, and the server validates that response. Thus, NT 4.0 creates a situation in which users might unknowingly provide their credentials to a bogus server. To prevent this fault, Kerberos supports mutual authentication in which the client authenticates to the server and the server authenticates to the client.

Transitive Trust
As in NT 4.0, a trust (i.e., a secret that two domain controllers share) between two Win2K domains facilitates cross-domain resource access and creates cross-domain account visibility. Microsoft simplifies trust creation and management in Win2K by letting you create trusts automatically as part of the domain hierarchy building process and allowing transitive trust.

Transitive trust means that if both europe.company.com and us.company.com trust company.com, then europe.company.com implicitly trusts us.company.com. Transitive trust reduces the number of trusts needed for authentication. For an example of how transitive trust simplifies authentication, see the sidebar "Kerberos Transitive Trust Examined," page 78.

Transitive trust is only a logical concept—no shared secret exists between the domain controllers of the domains that share a transitive trust. This setup means that for authentication to occur between entities on opposite ends of a transitive trust, the authentication process doesn't flow across the transitive trust but through the trust path (i.e., the tree of entities within a transitive trust). Microsoft claims that this referral process doesn't affect network traffic and the traffic this process generates is comparable to the traffic NT 4.0's pass-through authentication process generates. However, the referral process is evidence that Kerberos isn't suited for large distributed environments such as the Internet. Kerberos is an intranet-authentication protocol.

Win2K contains five basic types of trust relationships, as Table 1 outlines. You can view trust relationships through each domain objects' properties, as Screen 3 shows, or you can use the trustdom.exe command prompt utility. You can also use these tools to explicitly create trusts. End users who are working from Kerberos-compliant workstations can see the effect of transitive trusts when they log on. They can choose every domain with which their domain has a direct trust or an indirect trust. An NT 4.0 end user sees only the direct trusts of his or her domain.

Win2K Kerberos trusts that you implicitly or explicitly create within the same forest are transitive by default. Microsoft included a check box in Win2K beta 2 that let you turn off transitivity, but Microsoft didn't include this option in beta 3. Explicit trusts between forests or trusts to non-Win2K domains, such as a UNIX Kerberos domain, are nontransitive by default. So, if you want authentication interoperability between two domains that are part of different forests, you have to establish a trust relationship between the two domains manually.

Authentication Delegation
Using authentication delegation, user A can give rights to intermediary machine B to authenticate to an application server C as if machine B were user A. This setup means that application server C will base access control decisions on user A's identity rather than on machine B's account. Delegation is also known as authentication forwarding. In the Kerberos delegation process, user A forwards a ticket to intermediary machine B, and machine B uses user A's ticket to authenticate to application server C.

You can use delegation for authentication in multitier applications, such as Outlook Web Access (OWA). To use OWA, users access their mailboxes from a browser. In most cases, the Microsoft Exchange server that contains users' mailboxes isn't collocated to the Microsoft Internet Information Server (IIS). This means that IIS must authenticate to the Exchange server as if the IIS server were the user. In NT 4.0, this scenario causes problems when you want to use the NT LAN Manager (NTLM) protocol for authentication on both links (i.e., between the browser and IIS and between IIS and the Exchange server) because NTLM doesn't support delegation.

You can set delegation on each Win2K user and computer account by selecting the Account is trusted for delegation check box in an account's properties dialog box, as Screen 4 shows. You can also use the Win2K GPO Enable computer and user accounts to be trusted for delegation entry to set delegation.

Smart Card Logon
Win2K includes support for smart card logon, which provides much stronger authentication than password logon does because smart card logon relies on two-factor authentication. To log on, a user needs a smart card and the smart card's personal identification number (PIN) code. In addition, smart card logon blocks Trojan-horse attacks, in which intruders attempt to grab users' passwords out of memory.

In Win2K, an extension to the Kerberos protocol, PKINIT, makes smart card logon possible. During a PKINIT-based logon sequence, PKINIT replaces all occurrences of a user's password with the user's public key credentials, which the system has stored on a smart card. (For more information about PKINIT, see the Internet Engineering Task Force—IETF—document at http://search.ietf.org/ internet-drafts/ draft-ietf-cat-kerberos-pk-init-09.txt.)

To use smart card logon, you need to install a Win2K certificate server that has the necessary smart card logon certificate templates loaded. Users need a smart card reader and a smart card. Win2K currently supports smart cards from Gemplus and Schlumberger (both vendors provide a Cryptographic Service Provider—CSP—as a plug-in to Microsoft's CryptoAPI).

Smart card installation is straightforward thanks to Win2K's Plug and Play (PnP) support. In addition, Microsoft lets you define an enrollment agent to centralize and accelerate loading your corporate users' smart cards. An enrollment agent is an account with a special certificate that has permission to request and load other users' certificates.

Kerberos Is an Open Standard
Microsoft based its Kerberos implementation on the open standard that RFC 1510 defines (i.e., Kerberos V5), which means that Kerberos can provide authentication interoperability between Win2K and other OSs that support an RFC 1510-based Kerberos implementation.

Kerberos authentication interoperability comes in three flavors: A Win2K server hosts the Kerberos KDC and serves as a KDC for Win2K and other platform clients. Alternatively, a non-Win2K server hosts the Kerberos KDC and serves as a KDC for Win2K and other platform clients. Finally, you can create a cross-realm trust relationship between a Win2K domain and another platform to provide authentication interoperability. In this case, you have two KDCs—one KDC on each side of the trust relationship.

Authentication interoperability isn't simple and makes administration more complex. For example, to use a cross-realm trust to obtain authentication interoperability between Win2K and a UNIX platform, you must define an explicit mapping between each UNIX account that will access resources in your Win2K domain and a Win2K account, as Screen 5 shows. You must map each UNIX account because UNIX Kerberos account names are meaningless to Win2K domains. Windows environments use SIDs to identify accounts. UNIX accounts defined in a UNIX Kerberos domain don't have SIDs. The Security Identity Mapping dialog box shows mappings as part of a user object's advanced features.

In addition, companies outside the United States must consider the US export laws when planning authentication interoperability. These laws prohibit the export of software that uses encryption key lengths longer than 56 bits. The standard MIT Kerberos V5, which is available on US Web sites for UNIX platforms, uses 128-bit-length keys and isn't exportable. Win2K Kerberos is available in a domestic, nonexportable version, which uses 128-bit-length keys and an international, exportable version, which uses 56-bit-length keys. You can discover what version of Win2K you're running by looking at the properties of one of the following system files: schannel.dll, rsabase.dll, or ndiswan.sys.

In addition, although Microsoft implemented Kerberos as a Security Support Provider Interface (SSPI) plug-in, Kerberos supports the GSS_API token formats, which RFC 1964 defines. As a result, a UNIX application that supports GSS_API and a Win2K application can use Kerberos to mutually authenticate.

Looking Ahead
Microsoft has extended Win2K's authentication process by implementing Kerberos. Kerberos has symmetric cryptography roots that make it a typical LAN- and intranet-oriented authentication protocol. However, the inclusion of PKINIT is the first step toward increasing Kerberos' public-key-based authentication functionality and a wider application of Kerberos.

Corrections to this Article: