|
The
History of Kerberos Authentication
By DANIEL CALLOWAY,
TheWorldJournal.com
Kerberos provides authentication for many Net applications. However, it
does have its limitations.
Kerberos is the default authentication method for Windows 2000 and Windows
XP. Microsoft chose Kerberos for two basic reasons. Kerberos provides a
strong and highly tested design for network authentication; and secondly,
Kerberos is open source and thus Microsoft was able to add it's own
extensions to Kerberos for applications that it developed. Let's discuss
these two reasons in more detail.
Kerberos was developed by MIT (Massachusetts's Institute of Technology) as
part of Project Athena, which started in 1983 when MIT decided to
integrate network computers as part of its campus curriculum. MIT had
received grants from both IBM and DEC (Digital Equipment Corporation) and
had acquired multiple operating systems from various vendors. The goals of
Athena were the integration of a SSO (Single Sign-on), networked file
systems, a unified graphical environment, and a naming convention service.
Within 5 years, all these goals had been achieved.
Kerberos fit the bill with the SSO and secure remote authentication.
Kerberos also provided a secure replacement for the then widely used
Berkeley Unix networking commands that allowed individuals to authenticate
and sign on to a Unix network. As long as a user had an account with an
account name and password, he or she could access the Unix system.
Microsoft entered the world of networking with its first product known as
Windows for Workgroups. This product was acceptable for networking
computers but had its limitations since "sniffing" software in use at the
time of its introduction could be used by hackers to obtain the password
being sent across the network. Windows for Workgroups allowed users to
share files and printers across the network but didn't allow for login to
the network.
By the time Microsoft had developed Windows NT technology, the company had
advanced its capabilities of network login through the use of an
authentication method call CHAP (Challenge Handshake Application Protocol)
or challenge-response authentication. Instead of passing passwords across
the network which were easily sniffed out, challenge-response never sends
plaintext passwords. Instead, under the Microsoft scheme, a server sends
out an eight-byte challenge. The client converts the user's password into
3 separate DES (Digital Encryption System) keys. The eight bytes of
challenge get encrypted with each of the 3 keys, and all 24 bytes of the
response get sent back to the server. The server must know the user's
password hash, or communicate with a Domain Controller (DC) that does, as
it uses the hash to perform its own encryption of the challenge. If the
server's encrypted response matches all 24 bytes of the user's encrypted
response, then the user must have access to the password hash and he is
allowed to login to the network.
The biggest problem the challenge-response method had was all a hacker
needed to obtain the password of a user was to obtain the password hash.
If a would-be hacker wanted to view a user's files across the network, he
could obtain the password hash and create his own challenge-response thus
masquerading as another user on the network. Therefore, without having to
sniff for the password or crack the existing password a hacker could
subvert the authentication method.
Kerberos also relies on secret keys for its authentication. However,
unlike the challenge-response method, Kerberos uses encryption keys that
are created using a pseudo-random number generator rather than relying on
the password hash of the user. The user's password is still involved in
the process but only in the initial stages of logging on and the password
isn't transmitted across the network.
When a user logs in to a network that uses Kerberos, the logon process
contacts a part of Kerberos called the Authentication Service (AS). The
user requests a Ticket Granting Ticket (TGT) from the AS and the AS
responds by looking up the user's password hash, which it then uses as a
key for encrypting the session key. The user's logon process attempts to
decrypt the session key using the user's password hash as the encryption
key. If successful, the user may then use the TGT received to logon.
Password hashes are still stored on a server, or, in the case of
replicated servers, on many servers. In the Unix world, these servers are
called Key Distribution Centers or KDCs. Microsoft uses another means to
store hashes. These means are DCs or Domain Controllers and Active
Directory (via the LDAP or Lightweight Directory Access Protocol) for
storing hashes and keys.
Assuming a user has chosen to use a difficult-to-guess password. The
Kerberos login process, known as Security Support Provider Interface or
SPPI under Windows 2000 and XP, caches the session key and the TGT for
future use. Thus, the user only has to login once during a given session
and isn't required to login multiple times to acquire shared resources
across the network. This same key may be used to access other resources
across networks where trusts among networks have been established.
Kerberos 5 supports authentication between different Windows or Kerberos
domains, as well as 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.
Microsoft added its own proprietary authentication data - a list of
Security Identifiers called SIDs that are associated with an authenticated
user within each TGT. Kerberos 5 left room for vendor-based add-ons which
Microsoft designed into it. Since Kerberos 5 is open source, Microsoft was
able to do this.
In so doing, Microsoft's use of Kerberos meant that great strides were
achieved in Network Authentication techniques, that were heretofore not
possible. Kerberos remains the most widely used means of network
authentication today. Passwords, however, remain the weakness of Kerberos
since session keys must be cached on servers as well as Active Directory
or KDCs. Improvements in the Kerberos Authentication process will be in
the implementation of hardware devices to replace passwords for
authentication.
Nevertheless, if given the choice between using Windows 2000 in "mixed
mode" that allows for old-style authentication techniques and
Kerberos-only authentication, one should choose Kerberos every time.
Related web sites:
Massachusetts Institute of
Technology (MIT)
Microsoft
|
|
|