Kerberos: The basic protocol
The Kerberos authentication protocol is the default authentication protocol of Windows Server 2003. This section examines how the protocol works by breaking down the complexity of the protocol into five steps.
The first two excerpts provide important introductory information to consider while reading through the five steps. Then, step 1 explains how Kerberos uses symmetric key cryptography to authenticate entities. Step 2 describes the three different entities that the Kerberos protocol deals with and why a key distribution center (KDC) is necessary, step 3 sheds light on the connection between the session key and the master key and step 4 describes the two ways in which the KDC distributes the encrypted session keys to the user and the resource server. Finally, step 5 explores an important weakness in the protocol involving the Ticket Granting Ticket limiting the use of the master keys.
The two excerpts at the end pull together the five steps and include a brief explanation of how Kerberos extensions relate to Windows 2000, XP and Windows Server 2003. Helpful diagrams are provided throughout the section to help readers visualize the various steps.
The following sections explain the basic Kerberos protocol as it is defined in RFC 1510. Those not familiar with Kerberos may be bewildered by the need for numerous diverse keys to be transmitted around the network. In order to break down the complexity of the protocol, we will approach it in five steps:
- Step 1: Kerberos authentication is based on symmetric key cryptography.
- Step 2: The Kerberos KDC provides scalability.
- Step 3: A Kerberos ticket provides secure transport of a session key.
- Step 4: The Kerberos KDC distributes the session key by sending it to the client.
- Step 5: The Kerberos Ticket Granting Ticket limits the use of the entities’ master keys.
Kerberos is a computer network authentication protocol that works on the basis of ‘tickets’ to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. The protocol was named after the character Kerberos (or Cerberus) from Greek mythology, the ferocious three-headed guard dog of Hades (hellhound). Its designers aimed it primarily at a client–server model and it provides mutual authentication—both the user and the server verify each other’s identity. Kerberos protocol messages are protected against eavesdropping and replay attacks.
Kerberos builds on symmetric key cryptography and requires a trusted third party, and optionally may use public-key cryptography during certain phases of authentication. Kerberos uses UDP port 88 by default.
NTLM (Windows Network LAN Manager )is a challenge/response-based authentication protocol that is the default authentication protocol of Windows NT 4.0 and earlier Windows versions. For backward compatibility reasons, Microsoft still supports NTLM in Windows Vista, Windows Server 2003 and Windows 2003 R2, Windows 2000, and Windows XP.
Starting with Win2K, Microsoft implements Kerberos as the default authentication protocol for the Windows OS. This means that besides an NTLM authentication provider, every Windows OS since Win2K also includes a client Kerberos authentication provider.
Table 1, below, compares Kerberos to NTLM, the default authentication protocol of NT 4.0 and earlier Windows versions. The next paragraphs expand on some of the major feature differences (as listed in Table 1) between the Kerberos and the NTLM authentication protocols and explain why generally Kerberos is considered a better authentication option than NTLM.
- Faster authentication. When a resource server gets Kerberos authentication information (in Kerberos speak “tickets” and “authenticators”) from a client, the resource server has enough information to authenticate the client. The NTLM authentication protocol requires resource servers that aren’t domain controllers (DCs), to contact a DC to validate a user’s authentication request. This process is known as pass-through authentication. Thanks to its unique ticketing system, Kerberos doesn’t need pass-through authentication and therfore accelerates the authentication process.
- Mutual authentication. Kerberos can support mutual authentication. Mutual authentication means that not only the client authenticates to the service, but also the service authenticates to the client. Mutual authentication is a Kerberos option that the client can request. The support for mutual authentication is a key difference between Kerberos and NTLM. The NTLM challenge-response mechanism only provides client authentication. In the NTLM authentication exchange, the server generates an NTLM challenge for the client, the client calculates an NTLM response, and the server validates that response. Using NTLM, users might provide their credentials to a bogus server.
- Kerberos is an open standard. Microsoft based its Kerberos implementation on the standard defined in Request for Comments (RFC) 4120. RFC 4120 defines version 5 of the Kerberos protocol. Because Kerberos is defined in an open standard, it can provide single sign-on (SSO) between Windows and other OSs supporting an RFC 4120-based Kerberos implementation. You can download RFC 4120 from the Internet Engineering Task Force (IETF) at http://www.ietf.org. NTLM is a proprietary authentication protocol defined by Microsoft. The NTLM protocol is not specified in an open standard document (for example in an IETF RFC).
- Support for authentication delegation. Thanks to authentication delegation, a service can access remote resources on behalf of a user. What delegation really means is that user A can give rights to an intermediary machine B to authenticate to an application server C as if machine B was user A. This means that application server C will base its authorization decisions on user A’s identity rather than on machine B’s account. Delegation is also known as authentication forwarding. You can use delegation for authentication in multi-tier applications. An example is database access using a Web-based front-end application. In a multi-tier application, authentication happens on different tiers. In such a setup, if you want to set authorization on the database using the user’s identity, you should be capable of using the user’s identity for authentication both on the Web server and the database server. This is impossible if you use NTLM for authentication on every link, simply because NTLM doesn’t support delegation.
- Support for smart card logon. Through the Kerberos PKINIT extension, Win2K and later versions include support for the smart card logon security feature. Smart card logon provides much stronger authentication than password logon because it relies on a two-factor authentication. To log on, a user needs to possess a smart card and know its PIN code. Smart card logon also offers other security advantages. For example, it can block Trojan horse attacks that try to grab a user’s password from the system memory. The NTLM authentication protocol doesn’t support smart card logon.
Table 1: Kerberos-NTLM Feature Comparison
|Underlying Cryptographic Technology
||– Basic Kerberos: Symmetric Cryptography
– Kerberos PKINIT (this is the Kerberos subprotocol that supports smart card logon): Symmetric and Asymmetric Cryptography
|Trusted Third Party
||– Basic Kerberos: DC with Kerberos Key Distribution Center (KDC) service
– Kerberos PKINIT: DC with KDC service and Windows Enterprise Certification Authority (CA).
|Microsoft Supported Platforms
||Windows 95, Windows 98, Windows ME, NT 4.0, Win2K, XP, Windows 2003/R2, Vista
||Win2K, XP, Windows 2003/R2, Vista
||Slower authentication because of pass-through authentication
||Faster authentication because of unique ticketing system
||No mutual authentication
||Optional mutual authentication
||No support for delegation of authentication
||Support for delegation of authentication
||No native protocol support for smart card logon
||Native protocol support for smart card logon
||Proprietary Microsoft authentication protocol