Kerberos advantages

http://searchwindowssecurity.techtarget.com/originalContent/0,289142,sid45_gci1009961,00.html
http://searchwindowssecurity.techtarget.com/featuredTopic/0,290042,sid45_gci1014392,00.html?track=NL-122&ad=494045&ad=494041&ad=494039

Kerberos advantages
In this section, we will explain the key differences between the NTLM and the Kerberos authentication protocols and the advantages that Kerberos brings to the Windows 2000, Windows XP and Windows Server 2003 operating systems and their users. Many of the terms used in this section will be explained in greater detail later on in this chapter.
Faster authentication
The Kerberos protocol uses a unique ticketing system that provides faster authentication:
Every authenticated domain entity can request tickets from its local Kerberos KDC to access other domain resources.
The tickets are considered as access permits by the resource servers.
The ticket can be used more then once and can be cached on the client side.
When a resource server or the KDC gets a Kerberos ticket and a Kerberos authenticator from the client, the server has enough information to authenticate the client. The NTLM authentication protocol requires resource servers that are not domain controllers, to contact a domain contoller in order to validate a user's authentication request (this process is known as pass-through authentication). Thanks to its ticketing system, Kerberos does not need pass-through authentication. This is why Kerberos accelerates the authentication process. A downside to the ticketing system is that it puts a greater workload on the client. On the other hand, it offloads the resource servers; they must not bother about pass-through authentication anymore.
Mutual authentication
Kerberos supports mutual authentication. This means that the client authenticates to the service that is responsible for the resource and that the service also authenticates to the client. This is a big difference from NTLM. The NTLM challenge-response provides only client authentication: The server challenges the client, the client calculates a 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 RFC 1510 (this is Kerberos Version 5). This is why Kerberos can provide single sign-on (SSO) between Windows Server 2003 and other OSs supporting an RFC 1510-based Kerberos implementation. RFC 1510 can be dowloaded from the Internet Engineering Task Force (IETF) at http://www.ietf.org/.
Over the past years, Microsoft has been actively involved in the Kerberos standardization process. Microsoft software engineers participated in the creation of several Kerberos-related Internet drafts (see also http://www.ietf.org/).
Support for authentication delegation
Authentication delegation can be looked at as the next step after impersonation: Thanks to impersonation, a service can access local resources on behalf of a user; thanks to 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. In Kerberos terminology this basically means that user A forwards a ticket to intermediary machine B, and that machine B then uses user A's ticket to authenticate to application server C.
You can use delegation for authentication in multitier applications; an example of such an application is database access using a Web front end. In such a setup the browser, the Web server and the database server are all running on different machines. In a multitier application, authentication happens on different tiers. In such application 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 does not support delegation. We will come back to delegation in greater detail later on in this chapter.
Support for the smart card logon feature
Through the Kerberos PKINIT extension, both Windows 2000 and Windows Server 2003 include support for the smart card logon feature. The smart card logon feature provides much stronger authentication than the password logon feature does because it relies on a two-factor authentication: To log on, a user needs to possess a smart card and know its PIN code. The smart card logon feature 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 following excerpt is from Chapter 5 of the book "Windows Server 2003 security infrastructures" written by Jan De Clercq and available through Elsevier. Click for the complete book excerpt series.
Kerberos advantages
In this section, we will explain the key differences between the NTLM and the Kerberos authentication protocols and the advantages that Kerberos brings to the Windows 2000, Windows XP and Windows Server 2003 operating systems and their users. Many of the terms used in this section will be explained in greater detail later on in this chapter.
Faster authentication
The Kerberos protocol uses a unique ticketing system that provides faster authentication:
Every authenticated domain entity can request tickets from its local Kerberos KDC to access other domain resources.
The tickets are considered as access permits by the resource servers.
The ticket can be used more then once and can be cached on the client side.
When a resource server or the KDC gets a Kerberos ticket and a Kerberos authenticator from the client, the server has enough information to authenticate the client. The NTLM authentication protocol requires resource servers that are not domain controllers, to contact a domain contoller in order to validate a user's authentication request (this process is known as pass-through authentication). Thanks to its ticketing system, Kerberos does not need pass-through authentication. This is why Kerberos accelerates the authentication process. A downside to the ticketing system is that it puts a greater workload on the client. On the other hand, it offloads the resource servers; they must not bother about pass-through authentication anymore.
Mutual authentication
Kerberos supports mutual authentication. This means that the client authenticates to the service that is responsible for the resource and that the service also authenticates to the client. This is a big difference from NTLM. The NTLM challenge-response provides only client authentication: The server challenges the client, the client calculates a 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 RFC 1510 (this is Kerberos Version 5). This is why Kerberos can provide single sign-on (SSO) between Windows Server 2003 and other OSs supporting an RFC 1510-based Kerberos implementation. RFC 1510 can be dowloaded from the Internet Engineering Task Force (IETF) at http://www.ietf.org/.
Over the past years, Microsoft has been actively involved in the Kerberos standardization process. Microsoft software engineers participated in the creation of several Kerberos-related Internet drafts (see also http://www.ietf.org/).
Support for authentication delegation
Authentication delegation can be looked at as the next step after impersonation: Thanks to impersonation, a service can access local resources on behalf of a user; thanks to 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. In Kerberos terminology this basically means that user A forwards a ticket to intermediary machine B, and that machine B then uses user A's ticket to authenticate to application server C.
You can use delegation for authentication in multitier applications; an example of such an application is database access using a Web front end. In such a setup the browser, the Web server and the database server are all running on different machines. In a multitier application, authentication happens on different tiers. In such application 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 does not support delegation. We will come back to delegation in greater detail later on in this chapter.
Support for the smart card logon feature
Through the Kerberos PKINIT extension, both Windows 2000 and Windows Server 2003 include support for the smart card logon feature. The smart card logon feature provides much stronger authentication than the password logon feature does because it relies on a two-factor authentication: To log on, a user needs to possess a smart card and know its PIN code. The smart card logon feature 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.
Table 5.1 Kerberos -- NTLM Comparison

5.1.2 Comparing Kerberos to NTLM


Table 5.1 compares Kerberos, the default authentication protocol of Windows 2000 and Windows Server 2003, to NTLM, the default authentication protocol of NT4. It also lists the main features of both protocols introduced in the previous sections.