by Rik Farrow
Kerberos provides safer network authentication, but not perfect
Last October, I wrote that Kerberos had become the default authentication method for Windows 2000 and Windows XP. Some may wonder why Microsoft decided to use an Open Source styled authentication scheme rather than one that they had designed themselves. The answer really has two parts to it.
Kerberos really does provide a strong and tested design for network authentication. Kerberos also has features that Microsoft needed to make its new networked applications more secure. The older, Windows NT, authentication scheme has serious shortcomings, and organizations that can make the move to a pure Kerberos environment would be wise to do so.
I'll get to the second part of the answer near the end of this column, after explaining why Kerberos works so much better than other network authentication solutions.
MIT developed Kerberos as part of Project Athena. Project Athena began in 1983, when MIT decided to integrate networked computers as part of student curriculum. MIT had been given grants of money and equipment from IBM and DEC, so MIT had resources with which to work. They also had multiple operating systems, from different vendors, that they wanted to use in a college environment. Goals for the integration included single-sign on, networked file systems, a unified graphical environment, and a naming service. Amazingly, Project Athena achieved all of these goals within five years.
Kerberos provided the single-sign on, as well as a secure remote authentication method. Kerberos provided a secure replacement for the Berkeley UNIX networking commands, like rlogin and rsh. People could use rlogin the same way they would use telnet, and login with a user name and a password. Or, if administrators had set up trust between systems, the 'r' commands permitted logon without entering any password at all. Even users could set up trust between systems, as long as the users had accounts on the systems already. Outside of MIT and a few other places, the 'r' commands continued to be used into the late '90's (and some people still use them today).
The 'r' commands have two big problems. First, the trust mechanism had obvious weaknesses, for example, that any user could set up trust. Second, the 'r' commands, like other, earlier, IP network applications, could use passwords for authentication. Students could sniff network packets to obtain passwords. In these early days, password sniffing was relatively difficult, as software for packet capture and interpretation was in a primitive state. But, it was still possible.
When Microsoft entered the world of networking, with Windows for Workgroups, many years later, sniffing software had become common. But Workgroups for Windows used one password for each group, and sniffing these passwords was simple to do. On the other hand, Workgroups for Windows allowed only file and printer sharing, not login, as with comparable UNIX applications.
By the time Windows NT had been designed, Microsoft had advanced to using challenge-response authentication. Challenge-response authentication provides a real improvement in security. Instead of passing passwords across a network, just begging for someone to sniff them, challenge-response never sends plaintext passwords. In the Microsoft scheme, a server sends out an eight byte challenge. The client converts the user's password hash (derived from the user's password) into three DES (Data Encryption Standard) keys. The eight bytes of challenge get encrypted with each of the three keys, and all twenty-four bytes of response gets sent back to the server. The server must also either know the user's password hash, or communicate with a Domain Controller that does, and uses the hash to do its own encryption of the challenge. If the server's encrypted response matches the user's encrypted response (all 24 bytes), then the user must have access to the password hash.
The big problem with this challenge-response scheme is that all an
attacker needs to authenticate is the user's password hash.
Someone who wishes to
use networked resources while masquerading as another user just
needs to use the password hash to generate the response to any
challenge. Thus, without having to sniff or crack a password, the
authentication scheme can be subverted. The technique for hacking
Windows NT systems using this weakness became known as "passing
the hash", and stealing backup copies of the SAM (from the repair
directory) became part of many attacks.
Using a user's password hash for authentication introduced another problem for Microsoft. Microsoft designers wanted to include a mechanism for delegating authority, so that a client application could call another networked application (using DCOM), and have that application act on the user's behalf. The only way to do so involved passing the hash, and once the hash gets loose this way, anything can be done with it. The most recent version of Kerberos, version 5, supports delegation, a way out of this dilemma.
Just as the password hashes must remain secret, Kerberos also relies on secrets, but on different secrets. Instead of using the hash derived from a user's login password, Kerberos uses encryption keys, created using a pseudo-random number generator, for authentication. The user's password still gets involved, but only in the initial exchange, and not by being transmitted across the network.
When a user logs into a network that uses Kerberos, the logon process contacts part of Kerberos, called the Authentication Service (AS). The user includes a request for a Ticket Granting Ticket (TGT) to the AS, and the AS responds by looking up the user's password hash to use it as a key for encrypting the response. The AS sends back a Ticket Granting Ticket, along with an encrypted session key, as the response. The user's logon process attempts to decrypt the session key using the user's password hash as the encryption key. If this succeeds, the user may then use the Ticket Granting Ticket (TGT) he/she has received.
There are a couple of weaknesses you may have noticed with this scheme. First, password hashes are still stored on another server, or, in the case of replicated servers, many servers. In the world of UNIX, these servers are called Key Distribution Centers (KDC), and the hashes, as well as server keys, get encrypted and stored in a database. Microsoft uses Domain Controllers and Active Directory (via an LDAP interface) for storing hashes and keys. In either case, someone who can break into a KDC or a DC may acquire access to hashes and keys. At the time I was writing this article, Microsoft published a warning (search for Microsoft Knowledgebase article: Q328691) about a rootkit that changes security policy protecting Active Directory, as well as causing login failures.
The second weakness occurs during the authentication exchange. An attacker may make many requests, and keep trying different passwords, in a brute force attempt to decrypt the response from the AS. Or, an attacker can sniff the response, and perform an offline password cracking attempt. Microsoft guards against the brute force attack by requiring pre-authentication, the inclusion of an encrypted authenticator with the request itself. Any user that has a weak, easily guessed password, continues to be exposed to the second attack.
An attacker could also install a keystroke logger, like SilentLog, and capture users' passwords as they get entered. The Secure Attention Sequence (SAS) included with Windows NT and later systems only protects against trojan mules, programs that display fake login prompts, not against device driver level keystroke monitoring.
Let's assume that the user has chosen to use a difficult to guess (and therefore crack) password. The Kerberos login process, kinit under UNIX or the Security Support Provider Interface under Windows 2000 and XP, caches the session key and the TGT for future use. UNIX Kerberos just stores these credentials in a file, while Windows 2K uses memory. The UNIX system supports the ability for a root user to become any other user without a password, and this includes the use of Kerberos credentials. The Windows' security model does not make it as easy to usurp someone else's credentials.
Once a user has a TGT and a session key, he or she can use the
TGT and the session key for authentication to other network resources.
In Windows 2000 domains, this includes login to a workstation within
the domain. I don't want to go into detail about how Kerberos
does this, as these exchanges have been explained many times (see
Resources). But the main idea is that the KDC or DC generates
encryption keys, and sends one copy to each user and server, encrypted
with the user's login session key or the resource's secret key.
From then on
the client and the server use the new session key for authentication,
and optionally as a way to encrypt or checksum their communications.
The KDC or DC does not store session keys, just the keys for
resource servers and the hashes derived from user passwords.
Cached session keys must be protected on client and server systems.
Kerberos version 5, the newest version, has support for authentication between realms (different Kerberos or Windows domains), as well as support for delegation. In the case of cross-domain authentication, if the KDCs or DCs have exchanged secret keys, they can issue TGTs for each other's domains. These secret keys get generated when Windows domain administrators set up trust between DCs. Kerberos supports delegation, the ability of a server to act on behalf of a user, by issuing tickets that either include the IP address of the server (instead of the user's system) or by creating a ticket that can be used as a proxy.
In all cases, the Kerberos system really just acts as a trusted third party that asserts that your name (and possibly authorization data) is correct and can be trusted. The resource servers than make their own authorization decisions, for example, does the user 'rik' have read access to a particular file stored on a file server. And this is where the great divide between Microsoft Kerberos and any other version lies.
Microsoft added its own proprietary authorization data to tickets within
it implementation of Kerberos v5. Microsoft needed to have a way to
include its authorization data, the list of security IDs (SIDs) that
get associated with an authenticated user within each ticket.
Kerberos uses principles,
structured names, for authorization, but left room in RFC1510 for
vendor-based extensions, like the one Microsoft designed. While this
extension is not terribly useful on UNIX systems participating in a
domain, Microsoft's refusal to share the details of the extensions means
that mixed Kerberos domains must use a Windows 2000 DC, instead of
a UNIX KDC, which an organization might prefer. Microsoft's secret
extensions are the second reason Microsoft choose to use an Open
Sourced security protocol.
Kerberos represents a big advance in network authentication techniques, and continues to be the most widely used single-sign on system. Passwords remain the Achilles heal for Kerberos users. The safety of cached session keys, as well as the security of Active Directory or KDCs, also present other potential weaknesses in Kerberos implementations. Better use of hardware, to replace passwords and for protecting cached session keys, would improve the security of Kerberos today. If you have a choice between using Windows 2000 in "mixed mode", that allows for old-style authentication, and Kerberos only authentication, Kerberos provides the strongest security.
MIT papers about Kerberos, includes detailed explaination of the protocol: http://web.mit.edu/kerberos/www/papers.html
Technet article about use of Kerberos 5 and extensions within Win2K: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windows2000serv/deploy/kerberos.asp
The Microsoft proprietary extensions to Kerberos 5 used in W2K: http://ftp.die.net/mirror/banned/microsoft-kerberos-extensions.html
Page with lots of useful Microsoft Kerberos links: http://www.labmice.net/Security/kerberos.htm
Kerberos White Paper: http://www.cisco.com/warp/public/106/1.html
History of Athena project:
http://www-tech.mit.edu/V119/N19/history_of_athe.19f.html
USENIX NT conferences paper (2000) about Microsoft Kerberos v5 interoperability: http://www.usenix.org/events/lisa-nt2000/hill/hill_html/