Operating System
Windows 2000 Kerberos Authentication
White Paper
Abstract
The next generation of the Microsoft® Windows® operating system will adopt Kerberos as the default protocol for network authentication. An emerging standard, Kerberos provides a foundation for interoperability while enhancing the security of enterprise-wide network authentication.
Windows 2000 implements Kerberos version 5 with extensions for public key authentication. The Kerberos client is implemented as a security provider through the Security Support Provider Interface. Initial authentication is integrated with the Winlogon single sign-on architecture. The Kerberos Key Distribution Center (KDC) is integrated with other Windows 2000 security services running on the domain controller and uses the domain’s Active Directory as its security account database.
This white paper examines components of the protocol and provides detail on its implementation.
© 1999 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft, Active Desktop, BackOffice, the BackOffice logo, MSN, Windows, and WindowsNT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
Other product and company names mentioned herein may be the trademarks of their respective owners.
Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA
0999
Contents
Introduction
Authentication in Windows2000
Benefits of Kerberos Authentication
Standards for Kerberos Authentication
Extensions to the Kerberos Protocol
Overview of the Kerberos Protocol
Basic Concepts
Authenticators
Key Distribution
Session Tickets
Ticket-Granting Tickets
Authentication Across Domain Boundaries
Subprotocols
AS Exchange
TGS Exchange
CS Exchange
Tickets
What Is in a Ticket
What Clients Know About Tickets
How the KDC Limits a Ticket’s Lifetime
What Happens When Tickets Expire
Renewable TGTs
Delegation of Authentication
Proxy Tickets
Forwarded Tickets
Kerberos Components in Windows2000
Key Distribution Center
Account Database
Kerberos Policy
Delegation of Authentication
Preauthentication
Kerberos Security Support Provider
Credentials Cache
DNS Name Resolution
IP Transport
Authorization Data
Access Control in Windows2000
How the KDC Prepares Authorization Data
How Services Use Authorization Data
Why Authorization Data Is Signed
Interactive Logon
The Logon Process
Password Logon
Smart Card Logon
Preauthentication Data
Remote Logon
Security Support Provider Interface
Security Support Provider Negotiation
Example: Opening a File on a Remote Server
Negotiating a Security Support Provider
How the Client Initiates Authentication
How the Server Responds
Mutual Authentication
Example: Cross-Domain Authentication
Interoperability
Scenarios
For More Information
Introduction
This paper provides a technical introduction to how the Microsoft® Windows®2000 operating system implements the Kerberos version 5 authentication protocol. The paper includes detailed explanations of important concepts, architectural elements, and features of Kerberos authentication. The first section, “Overview of the Kerberos Protocol,” is for anyone unfamiliar with Kerberos authentication. Following this introduction to the protocol are several sections with details of Microsoft’s implementation in Windows2000. The paper concludes with a brief discussion of requirements for interoperability with other implementations.
Authentication in Windows2000
Windows2000 supports several protocols for verifying the identities of users who claim to have accounts on the system, including protocols for authenticating dial-up connections and protocols for authenticating external users who access the network over the Internet. But there are only two choices for network authentication within Windows2000 domains:
- Kerberos Version 5. The Kerberos version 5 authentication protocol is the default for network authentication on computers with Windows2000.
- Windows NT LAN Manager (NTLM). The NTLM protocol was the default for network authentication in the WindowsNT® 4.0 operating system. It is retained in Windows2000 for compatibility with downlevel clients and servers. NTLM is also used to authenticate logons to standalone computers with Windows2000.
Computers with Windows 3.11, Windows 95, Windows 98, or Windows NT 4.0 will use the NTLM protocol for network authentication in Windows2000 domains. Computers running Windows2000 will use NTLM when authenticating to servers with WindowsNT 4.0 and when accessing resources in WindowsNT 4.0 domains. But the protocol of choice in Windows2000, when there is a choice, is Kerberos version 5.
Benefits of Kerberos Authentication
The Kerberos protocol is more flexible and efficient than NTLM, and more secure. The benefits gained by using Kerberos authentication are:
- More efficient authentication to servers. With NTLM authentication, an application server must connect to a domain controller in order to authenticate each client. With Kerberos authentication, the server does not need to go to a domain controller. It can authenticate the client by examining credentials presented by the client. Clients can obtain credentials for a particular server once and reuse them throughout a network logon session.
- Mutual authentication. NTLM allows servers to verify the identities of their clients. It does not allow clients to verify a server’s identity, or one server to verify the identity of another. NTLM authentication was designed for a network environment in which servers were assumed to be genuine. The Kerberos protocol makes no such assumption. Parties at both ends of a network connection can know that the party on the other end is who it claims to be.
- Delegated authentication. Windows services impersonate clients when accessing resources on their behalf. In many cases, a service can complete its work for the client by accessing resources on the local computer. Both NTLM and Kerberos provide the information that a service needs to impersonate its client locally. However, some distributed applications are designed so that a front-end service must impersonate clients when connecting to back-end services on other computers. The Kerberos protocol has a proxy mechanism that allows a service to impersonate its client when connecting to other services. No equivalent is available with NTLM.
- Simplified trust management. One of the benefits of the Kerberos protocol is that trust between the security authorities for Windows2000 domains is by default two-way and transitive. Networks with multiple domains no longer require a complex web of explicit, point-to-point trust relationships. Instead, the many domains of a large network can be organized in a tree of transitive, mutual trust. Credentials issued by the security authority for any domain are accepted everywhere in the tree. If the network includes more than one tree, credentials issued by a domain in any tree are accepted throughout the forest.
- Interoperability. Microsoft’s implementation of the Kerberos protocol is based on standards-track specifications recommended to the Internet Engineering Task Force (IETF). As a result, the implementation of the protocol in Windows2000 lays a foundation for interoperability with other networks where Kerberos version 5 is used for authentication.
Standards for Kerberos Authentication
The Kerberos protocol originated at MIT more than a decade ago, where it was developed by engineers working on Project Athena.[1] The first public release of the protocol was Kerberos version 4. Following wide industry review of the protocol, its authors developed and released Kerberos version 5. That version is now on a standards track with the IETF. The implementation of the protocol in Windows2000 closely follows the specification defined in Internet RFC 1510.[2] In addition, the mechanism and format for passing security tokens in Kerberos messages follows the specification defined in Internet RFC 1964.[3]
Extensions to the Kerberos Protocol
Windows2000 implements extensions to the Kerberos protocol that permit initial authentication using public key certificates rather than conventional shared secret keys. This enhancement allows the protocol to support interactive logon with a smart card. The extensions for public key authentication are based on a draft specification submitted to the IETF working group by a number of third parties with interests in public key technology.[4] Microsoft is participating in the standards process and will continue to support its efforts.
Overview of the Kerberos Protocol
The Kerberos authentication protocol provides a mechanism for mutual authentication between a client and a server, or between one server and another, before a network connection is opened between them. The protocol assumes that initial transactions between clients and servers take place on an open network where most computers are not physically secure, and packets traveling along the wire can be monitored and modified at will. The assumed environment, in other words, is very much like today’s Internet, where an attacker can easily pose as either a client or a server, and can readily eavesdrop on or tamper with communications between legitimate clients and servers.
Basic Concepts
The Kerberos protocol relies heavily on an authentication technique involving shared secrets. The basic concept is quite simple: If a secret is known by only two people, then either person can verify the identity of the other by confirming that the other person knows the secret.
For example, let’s suppose that Alice often sends messages to Bob and that Bob needs to be sure that a message from Alice really has come from Alice before he acts on its information. They decide to solve their problem by selecting a password, and they agree not to share this secret with anyone else. If Alice’s messages can somehow demonstrate that the sender knows the password, Bob will know that the sender is Alice.
The only question left for Alice and Bob to resolve is how Alice will show that she knows the password. She could simply include it somewhere in her messages, perhaps in a signature block at the end—Alice, Our$ecret. This would be simple and efficient and might even work if Alice and Bob can be sure that no one else is reading their mail. Unfortunately, that is not the case. Their messages pass over a network used by people like Carol, who has a network analyzer and a hobby of scanning traffic in hope that one day she might spot a password. So it is out of the question for Alice to prove that she knows the secret simply by saying it. To keep the password secret, she must show that she knows it without revealing it.
The Kerberos protocol solves this problem with secret key cryptography. Rather than sharing a password, communication partners share a cryptographic key, and they use knowledge of this key to verify one another’s identity. For the technique to work, the shared key must be symmetric—a single key must be capable of both encryption and decryption. One party proves knowledge of the key by encrypting a piece of information, the other by decrypting it.
Authenticators
A simple protocol that uses secret key authentication begins when someone is outside a communications door and wants to go in. To gain entry, this person presents an authenticator in the form of a piece of information encrypted in the secret key. The information in the authenticator must be different each time the protocol is executed, otherwise an old authenticator could be reused by anyone who happens to overhear the communication. On receiving an authenticator, the person guarding the door decrypts it and knows from what is inside whether decryption was successful. If it was successful, the doorkeeper knows that the person presenting the authenticator has the correct key. Only two people have the correct key; the doorkeeper is one of them, so the person who presented the authenticator must be the other.
If the person outside the door wants mutual authentication, the same protocol can be executed in reverse, with a slight difference. The doorkeeper can extract part of the information from the original authenticator, encrypt it in a new authenticator, and then give the new authenticator to the person waiting outside the door. The person outside the door can then decrypt the doorkeeper’s authenticator and compare the result with the original. If there is a match, the person outside the door will know that the doorkeeper was able to decrypt the original, so he must have the correct key.
It will help to walk through an example. Suppose Alice and Bob decide that before transferring any information between their computers, each will use knowledge of a shared secret key to verify the identity of the party at the other end of the connection. In situations where Alice is the wary guest and Bob is the suspicious host, they agree to follow this protocol:
- Alice sends Bob a message containing her name in plaintext and an authenticator encrypted in the secret key she shares with Bob. In this protocol, the authenticator is a data structure with two fields. One field contains information about Alice. For simplicity, let’s say this is another instance of her name. The second field contains the current time on Alice’s workstation.
- Bob receives the message, sees that it is from someone claiming to be Alice, and uses the key he shares with Alice to decrypt the authenticator. He extracts the field that contains the time on Alice’s workstation, and evaluates the time.
Bob’s task will be easier if his clock is reasonably synchronized with Alice’s, so let’s suppose both Alice and Bob use a network time service to keep their clocks fairly close. Let’s say the time skew is never more than five minutes. This way, Bob can compare the time from the authenticator with the current time on his clock. If the difference is greater than five minutes, he can automatically reject the authenticator.
If the time is within the allowable skew, it’s probable that the authenticator came from Alice, but Bob still does not have proof that the authenticator actually came from her. Another person might have been watching network traffic and might now be replaying an earlier attempt by Alice to establish a connection with Bob. However, if Bob has recorded the times of authenticators received from Alice during the past five minutes, he can defeat attempts to replay earlier messages by rejecting any message with a time that is the same as or earlier than the time of the last authenticator. If this authenticator yields a time later than the time of the last authenticator from Alice, then this message must be from Alice.
- Bob uses the key he shares with Alice to encrypt the time taken from Alice’s message and sends the result back to her.
Note that Bob does not send back all of the information taken from Alice’s authenticator, just the time. If he sent back everything, Alice would have no way of knowing whether someone posing as Bob had simply copied the authenticator from her original message and sent it back to her unchanged. He sends just a piece of the information in order to demonstrate that he was able to decrypt the authenticator and manipulate the information inside. He chooses the time because that is the one piece of information that is sure to be unique in Alice’s message to him.
Alice receives Bob’s reply, decrypts it, and compares the result with the time in her original authenticator. If the times match, she can be confident that her authenticator reached someone who knows the secret key needed to decrypt it and extract the time. She shares that key only with Bob, so it must be Bob who received her message and replied.
Figure 1: Mutual authentication (Alice-Bob)
Key Distribution
One problem with the simple protocol described in the preceding section is that it does not explain how or where Alice and Bob got a secret key to use in sessions with each other. If they are people, Alice and Bob could meet, perhaps in an alley, and agree on a secret key. But that method will not work if Alice is a client program that is running on a workstation and Bob is a service that is running on a network server. There is also the further problem that the client, Alice, will want to talk to many servers and will need keys for each of them. Likewise, the service, Bob, will talk to many clients and will need keys for each of them as well. If each client needs to have a key for every service, and each service needs one for every client, key distribution could quickly become a tough problem to solve. And the need to store and protect so many keys on so many computers would present an enormous security risk.