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.