NT's Security Future
In the past couple of months, I've explained what happens under the hood when
Windows NT 3.x and 4.0 authenticate a user ID. But, NT 5.0 will arrive soon, and
then everything you know will be wrong. Lots of things will change in NT 5.0. It
will use Kerberos authentication, which has been in the UNIX and Internet world
for a while. This month, let's see how Kerberos works and how it applies to NT
5.0 user authentication.
Suppose a user whose account name is Dawn has a PC with IP address 2.2.2.2, and she wants to access data on a server \\DATAPLACE on the network. She and \\DATAPLACE are on the same domain, which has a domain controller named \\BIGDOG. How do Dawn, \\DATAPLACE, and \\BIGDOG interact to get Dawn to her data?
Kerberos seeks to solve the authentication problem: User Dawn wants server \\DATAPLACE to recognize her over the network, so she has to prove that she is the person who owns domain user account Dawn. Of course, Dawn has a password to her domain account, so \\DATAPLACE can authenticate Dawn by asking her, "What's your domain password?" Once Dawn gives her password, \\DATAPLACE can ask \\BIGDOG, "Is that really Dawn's password?" This method is not a good idea because Dawn's password gets transmitted over the wire from Dawn's PC to \\DATAPLACE, and then from \\DATAPLACE to \\BIGDOG. Anyone with a network sniffer can capture Dawn's password. Kerberos improves on this method, however, and handles user authentication without transmitting any clear-text passwords across the network.
Kerberos Simplified
With Kerberos, both users and services have passwords. So, Dawn has a
password, and the file server service on \\DATAPLACE has a password, which is
for the file server service only. If, for example, Internet Information Server
(IIS) is running on \\DATAPLACE, the copy of IIS on \\DATAPLACE will have a
different password from the copy on the file server service. (I've simplified
this example to expose the big idea; I'll fill in the gaps later.)
When Dawn tries to access data on \\DATAPLACE, her file-sharing client software goes first not to \\DATAPLACE, but to \\BIGDOG, where Dawn's software requests a ticket to the file server module on \\BIGDOG. \\BIGDOG looks up Dawn's password and \\BIGDOG's password and creates a Kerberos ticket. \\DATAPLACE will use that ticket to authenticate Dawn.
First, \\BIGDOG creates a message ultimately for \\DATAPLACE, saying something like, "If you got this message from a machine with IP address 2.2.2.2, you got this message from user Dawn." Second, \\BIGDOG takes that message and encrypts it using \\DATAPLACE's password. Kerberos' encryption method uses one string of characters to encrypt another string of characters. Encrypting the message, "Meet me at 8 pm," using the password "sentinel," might yield an encrypted message like "sk3knalef9m3poh." The encryption method is symmetrical: The receiver can decrypt the message using the same password as the sender; knowing that the password is sentinel and the message is sk3knalef9m3poh is sufficient information to decrypt the message. Third, \\BIGDOG takes that encrypted message and adds a plain-text message to Dawn saying, "Give this to \\DATAPLACE." Fourth, \\BIGDOG takes the whole message--the part encrypted in \\DATAPLACE's password and the plain-text part--and encrypts it using Dawn's password. Then \\BIGDOG sends the ticket to Dawn.
Dawn's PC receives the entire encrypted ticket. The PC knows Dawn's password, so it decrypts the message, yielding a plain-text message saying, "Send this to \\DATAPLACE," and a message encrypted with \\DATAPLACE's password. Dawn can't tamper with the message for \\DATAPLACE because she doesn't have \\DATAPLACE's password. Her machine then sends that message to \\DATAPLACE.
The security software in \\DATAPLACE sees that it's received a message from a machine with IP address 2.2.2.2. It decrypts the message, which says, "If you got this message from a machine with IP address 2.2.2.2, you got this message from user Dawn." The message came from 2.2.2.2, so \\DATAPLACE is now pretty sure that Dawn is on the other end of the line. It can look up the access control list (ACL)/Security Descriptor on the share to see whether Dawn is authorized to access the share.
Kerberos Details
Kerberos implementations vary, but I've described roughly how Kerberos
works. My example left out a few details. Let me fill them in now.
My example showed how \\DATAPLACE can be sure that it is talking to Dawn, but Kerberos usually provides more than just a name and address. Tickets have a lifetime. They expire after a given number of hours. No one knows how long that time will be in NT 5.0. Microsoft people say they haven't nailed down the details, but I've seen non-NT implementations that time out after eight hours. The timeout adds protection from intruders; in contrast, once you're connected to an NT file server under NT 4.0 or NT 3.x, you can stay on as long as you like. If you (or a systems administrator) don't break the connection, NT never re-examines your network credentials. Kerberos-based systems force your system to present your credentials every few hours.
Additionally, Kerberos implementations provide a session password for the user and the service. When Dawn requests access to the file server on \\DATAPLACE, a typical Kerberos implementation will not only pass along Dawn's name, IP address, and timeout value, but will randomly generate a password and put that password in both \\DATAPLACE's part of the ticket and Dawn's part of the ticket. If Dawn tries to access \\DATAPLACE at 8 am on Tuesday, the part of the ticket intended for \\DATAPLACE might contain the message, "If you got this from IP address 2.2.2.2, the user is Dawn; until 4 pm Tuesday, the two of you can use the password 'avocado' to communicate." Dawn's part of the message will, again, contain \\DATAPLACE's portion, encrypted in \\DATAPLACE's password, and the message, "Send the encrypted part of this message to \\DATAPLACE. Until 4 pm Tuesday, the two of you can use the password 'avocado' to communicate."
The value of this one-time-only session password depends on who's using it. If all I want is to have a service recognize me, the password is irrelevant. But NT-to-NT communications often occur via an encrypted remote procedure call (RPC), so perhaps NT can use these session passwords to encrypt RPC communications.
When a domain controller verifies you to an NT machine, that domain controller passes along information about you--in particular the Security Identifiers (SIDs) of your user account and any domainwide global groups that you belong to. Kerberos can easily include that information, and no doubt will.
Why Kerberos?
Why Kerberos? Three reasons: First, you get a bit less network chatter in a
domain login than with NT 3.x or 4.0.
Second, the example I gave you is a one-way authentication. It proved to a file server that a particular person was who she claimed to be. But sometimes, a person wants to know that the server is what it claims to be. Kerberos provides that service through mutual authentication.
The third reason is transitive realms. Kerberos has a notion like NT domains, Kerberos realms. One Kerberos realm can grant authentication abilities to another Kerberos realm. In NT-ese, with Kerberos, you can support transitive trust relationships. So if you support 100 domains, you no longer have to face the possibility of building and maintaining up to 9,900 trust relationships.
Embracing Kerberos as an authentication tool moves Microsoft farther from proprietary-based systems and closer to standards-based systems. This development gives you another reason to look forward to NT 5.0.