August 1999
| Exploring Kerberos, the Protocol for Distributed Security in Windows 2000 |
| For Windows 2000, Microsoft has chosen a new core security protocol. In this new system, the default protocol for distributed security is something called Kerberos. NTLM is still supported as is the Secure Sockets Layer (SSL) protocol, but Kerberos is now the fundamental security protocol. |
| This article assumes you're familiar with Windows NT |
|
David Chappell (david@chappellassoc.com) is Principal of Chappell & Associates (http://www.chappellassoc.com). This article is drawn from his forthcoming book on Windows 2000 distributed services, which will be published by Microsoft Press this year. |
|
Distributed security is a critically important subject. But since security can seem complex, many developers have tended to shy away from really getting a handle on how it works. Avoiding the topic is a bad idea, though, for a couple of reasons. First, it's difficult to fully understand what's going on in a distributed environment without a solid grasp of what the underlying distributed security mechanism is doing. Second, distributed security can actually be a really interesting topic.
In Microsoft® Windows NT 4.0, the primary protocol that applications rely on for distributed security is NTLM. The acronym stands for Windows NT LAN Manager, which gives you some idea of just how ancient this protocol is. NTLM is not a bad security protocol, but it's not exactly state of the art. For Windows 2000, Microsoft has chosen a new core security protocol. In this new system, the default protocol for distributed security is something called Kerberos. NTLM is still supported, of course, as is the Secure Sockets Layer (SSL) protocol, but Kerberos is now the fundamental security protocol. Kerberos Basics Kerberos was created at the Massachusetts Institute of Technology in the early 1980s. (Kerberos is the name of the three-headed dog that guards Hades, which makes it an apt name for a security service.) The current version, Kerberos version 5, has been published by the IETF (Internet Engineering Task Force) as RFC 1510 (http://www.ietf.org/rfc/rfc1510.txt), and Windows 2000 implements Kerberos as described in this standard. Like all standards, this one provides choices for its implementors, some of which I'll describe later. In Windows 2000, Kerberos is implemented as a Security Service Provider (SSP) that is accessible via the Security Support Provider Interface (SSPI). Applications can directly access Kerberos services through SSPI. In fact, SSL and NTLM are also implemented as SSPs in Windows 2000, allowing their services to be accessed through the same interface. Most applications won't use SSPI directly, however. For example, as shown in Figure 1, a Distributed COM (DCOM) or COM+ application uses the security interfaces DCOM provides. (Although it's not shown in the diagram, DCOM actually relies on the authenticated RPC interfaces, which are the direct users of SSPI in this case.) Other application protocols work in much the same way to shield developers from the details of SSPI. The key point to remember is that you don't need to worry about the details of how distributed security is provided—whatever SSP is used handles them more or less transparently. |
 |
| Figure 1 Using SSPI |
|
The Kerberos SSP can provide three security services: authentication, proving you are who you say you are; data integrity, ensuring that data isn't modified in transit; and data privacy, ensuring that data isn't read in transit. Kerberos uses encryption to provide each service. Windows 2000 has built-in support for both public key and secret key encryption, but Kerberos relies mostly on secret key encryption (also called private key, symmetric, single key, or shared secret encryption).
In secret key encryption, the same key—really just some string of bytes—is used to encrypt and decrypt data. Suppose, for instance, that you want to send me a private message indicating that the Acme Corporation has been sold. To do this, you can encrypt that message using some key value (in general, longer keys provide better security). You can then send me the resulting encrypted information, sometimes called the ciphertext, without fear of anyone else reading it—assuming you've chosen a strong encryption algorithm and an appropriate key. To decrypt the message, I must use the same key that you used for encryption. Rather than require its users (known as principals) to invent special encryption keys, Kerberos just uses ordinary passwords. But those passwords aren't used to encrypt the actual data sent between clients and servers in a Windows 2000 domain. Instead, password-based keys are used only during login and other dynamically created keys are used to encrypt and decrypt data sent across the network. And to be completely correct, the key a principal uses to log in is really a hash of that principal's password. A hash algorithm (sometimes called a message digest or a checksum) produces a bitstring that is a function of the information being hashed, but that can't be used to recover the original input value. In other words, hashes are one-way. Therefore, given a hashed password value, it's not possible to recover the original password. In Windows 2000, users have passwords, server applications that want to authenticate their users have passwords, and all computers in a domain have passwords. Anything with a password qualifies as a security principal. The Kerberos server itself, known as the Key Distribution Center (KDC), runs on a domain controller where it has access to the hashed password for every principal in its domain. (This information is stored in each principal's Active Directory™ entry, also kept on a domain controller.) By default, the cleartext password itself is not stored in the directory—only a hashed version is kept there. To allow password synchronization with other directory services, an administrator can cause the user's original cleartext password to be stored along with the hashed version. Whichever option is chosen, each principal's password information is stored using the strongest level of encryption available. Despite this protection, domain controllers should still be kept physically secure. A determined attacker with unlimited time to crack your domain's most important systems is something you definitely want to avoid. The Kerberos protocol allows negotiation of the encryption algorithm. Most Kerberos implementations default to the Data Encryption Standard (DES), the keys for which have an effective length of 56 bits. To allow interoperability with other implementations, Windows 2000 Kerberos supports DES, but its default choice for an encryption algorithm is RC4. In North America, 128-bit RC4 keys are used, while the international version will support only 56-bit keys. RC4 is both faster and more secure than DES, and in a standard Windows 2000 environment all Kerberos encryption uses this newer algorithm. That secret key encryption is used to send data privately is obvious, but it's less than obvious how you can use it for authentication, Kerberos's most important function. To see how this might be done, imagine that you and I share a key, and suppose I send you some message encrypted using that key. If you use this key to decrypt the message, and that decryption works correctly, then this message must have been encrypted using that same key. If only you and I know that key, this message must have come from me. By proving knowledge of a key in this way, I can authenticate myself. But this simple method is not very practical. Each client/server pair would have to share a secret key, which means that you'd need a separate password for every service you wanted to access securely. This is not a very appealing prospect. How, then, is it possible to effectively use secret key encryption for authentication? The answer is provided by Kerberos.
Riding the Kerberos Train: Tickets, Please When a user wants to prove her identity to a server app on some other system, that user must somehow provide the server with an appropriate ticket. Each ticket allows a specific user to prove its identity to a specific server application, such as a particular DCOM application. As shown in Figure 2, a Kerberos ticket contains both encrypted and unencrypted information. Although Figure 2 is somewhat simplified, the unencrypted part of a ticket contains two primary pieces of information: the name of the Windows 2000 domain in which this ticket was issued (the Kerberos standard uses the term "realm" rather than "domain"), and the name of the principal this ticket identifies. |
 |
| Figure 2 Ticket |
The encrypted part of the ticket contains quite a bit more information. Here are the fields:
All of these fields are encrypted using the key of the server application this ticket targets. Neither the user nor any attackers listening on the network can read or modify the encrypted fields in a ticket, since they don't know the server password used for encryption. The fields carrying the ticket's start and end times are worth some extra explanation. Every ticket has a finite lifetime, which means an attacker has only a limited period in which to crack the ticket's encryption, making a successful attack more difficult, and a stolen ticket can be used only until it expires. (Actually, using somebody else's ticket requires knowing more than just the ticket itself, as I'll describe later.) It also means that every user's tickets expire periodically, which could be a nuisance. Fortunately, Windows 2000 will automatically renew a user's tickets as long as that user remains logged in. Logging In When a user wants to prove her identity to a server, she must acquire a ticket to that server. In fact, virtually the entire Kerberos protocol is devoted to acquiring and using tickets. Before launching into a description of how the protocol works, it's worth taking a moment to explain the notation used in the rest of this article. I've mostly adopted what has become the standard Kerberos notation:
As shown in Figure 3, the user's login request causes the client system to send a message to a KDC running on a domain controller. The message contains several things, including the user's name; preauthentication data, which consists of a timestamp encrypted using KC, a hash of the user's password, as a key; and a request for a ticket-granting ticket (TGT). A TGT is just an ordinary ticket, like the one shown in Figure 2, and as with all tickets, it is used to prove a user's identity. But the TGT is used in a slightly special way; as you'll see, the Kerberos SSP on the client presents it to the KDC when requesting tickets to specific server applications. |
 |
| Figure 3 Getting a Ticket Granting Ticket |
|
When this request arrives at the domain controller, the KDC looks up the entry associated with the user's principal name in the specified domain's Active Directory database. From this entry, the KDC extracts a hash of the user's password, then uses this value to decrypt the preauthentication data. If that decryption works and results in a very recent timestamp, the KDC can be certain that this user is who they claim to be, since the user has demonstrated knowledge of the correct password. (Note that this was done without having that password sent over the network. To provide its services, Kerberos never requires sending a user's password across the network.) If the decryption fails, the user must have entered the wrong password, and the login will fail.
If the preauthentication data is correctly validated, the KDC next builds and sends back to the client machine what it asked for: a ticket-granting ticket. Like all tickets, this one contains the user's name and the name of the domain in which it was issued, along with a session key (KC,K, generated randomly by the KDC), the valid start and end times for this ticket, and various flag values. Finally, in the Authorization Data field, the TGT contains privileges and Windows 2000 Security Identifiers (SIDs) identifying this user and the groups the user belongs to (these are extracted from the user's entry in Active Directory). As always, part of the ticket is encrypted using the key of the server to which this ticket will be sent. Since the TGT is used only to request other tickets, and since only the KDC can give out tickets, the encrypted part of the TGT is encrypted using KK, the key of the KDC itself. Along with the TGT, the KDC also sends back to the client machine the session key KC,K, the same value the server placed in the TGT. This session key is sent encrypted using the user's hashed password as a key. When the client system gets this message, it uses the hash of whatever password the user has entered to decrypt the received session key. In Kerberos for Windows 2000, this decryption will always work, since only users who demonstrate knowledge of the correct password via the preauthentication data will get this message sent to them at all. Sending preauthentication data is optional in the Kerberos standard, an option that Windows 2000 Kerberos always uses. Other versions of Kerberos don't typically use it. A Windows 2000 KDC can also accept requests without preauthentication data, allowing it to be used with Kerberos clients that can't generate that information. In this case, the user's identity is verified when the received session key is decrypted (see Figure 3). If the correct password is entered, decryption of the client/Kerberos session key KC,K will succeed. If the user types the wrong password, that decryption will fail, and the user will not know the session key. And, as described next, getting tickets to other services requires knowing this key. Authenticating to a Remote Service Once a user has successfully logged in, that user is likely to begin accessing services running on other computers in the network. To do this securely, the user must at a minimum have some way of proving her identity to those services. In Windows 2000, the Kerberos SSP can present a TGT to the KDC, requesting a ticket to a specific service. To distinguish them from TGTs, these tickets are sometimes called service tickets, but the format is identical for both types. That ticket is then sent to the target service, which can use it to determine exactly who this user is. (In fact, immediately after acquiring a TGT, every client completes the login process by requesting a service ticket for its own computer, allowing it to prove its identity to local services.) While this sounds simple enough, the details are not especially straightforward. Take a deep breath, and let's dive in. Suppose a user wants to access a DCOM server application (called, say, Server S) running on some remote system. The user will load the client part of the application, and this client will attempt to create a remote DCOM object. If the application uses Kerberos for authentication, that client application will need to acquire a ticket on behalf of its user before it can access the server. Recall that each ticket authenticates a particular user to a particular service, and since the client part of a distributed application runs on behalf of the user, that client acquires tickets that prove the user's identity to the server. When the client application makes its first remote request to the server, a ticket request is automatically made to the KDC, as shown in Figure 4. (Programmers do not generally code this request explicitly. Instead, the developer of the application just requests that Kerberos be used and everything else happens under the covers.) This request contains several things, including the user's TGT, the name of the server application for which a service ticket is requested (which in this case is Server S), and an authenticator proving that this TGT belongs to this user. The authenticator contains the current time and the user's name, and it is encrypted using the session key KC,K that was received at login. |
 |
| Figure 4 Getting and Using a Service Ticket |
|
When the KDC receives this request, it decrypts the TGT (recall that only the KDC knows KK, the key used to encrypt this ticket), then extracts the session key KC,K from the ticket. It then uses this session key to decrypt the authenticator. The authenticator serves two purposes. First, because it is encrypted using the client/Kerberos session key, it proves that the user is who she claims to be, since as described earlier, the only way to get this session key is to type the correct password at login. If the KDC's attempted decryption of the authenticator is successful, the client system must be in possession of the session key.
Second, because the authenticator contains a timestamp, it prevents an attacker from grabbing a user's TGT off the network, then presenting it as its own. A new authenticator is created each time a ticket is used, and because the timestamp is encrypted using the session key, known only to the client system and the KDC, a valid authenticator cannot be created by anyone else. And to prevent resending authenticators, a KDC will reject any authenticator whose timestamp is too old. (By default, an authenticator's timestamp must differ by no more than 5 minutes from that of the server that receives it.) This implies that the clocks on machines using Kerberos must be at least loosely synchronized, so Windows 2000 uses the IETF-defined Simple Network Time Protocol (SNTP) for clock synchronization. To further ensure that the user isn't presenting a stolen ticket, the KDC also verifies that the IP address in the TGT matches the IP address of the system that sent this request. If everything checks out, the KDC will believe that this user is who she claims to be, and will send back the requested service ticket. The KDC copies some fields from the TGT into the new service ticket, including the user's name, domain, and authorization data. It sets the service ticket's flags and start/end times appropriately, and generates a new random session key, KC,S, which it places in the ticket. (As described later, this key can be used to encrypt information sent between the client and Server S.) The KDC then encrypts this new ticket using KS, Server S's secret key, and sends it back to the client, along with the new session key KC,S. To prevent attackers from learning this new key, it's sent encrypted using the session key shared by Kerberos and the client. Finally, the goal of this entire exercise can be achieved: the user can prove her identity to the server application. On its first request to Server S, the client presents the service ticket it just received along with an authenticator encrypted using KC,S. This information is sent as part of whatever protocol is being used between client and server. With DCOM, for example, the ticket and authenticator are carried in a particular field in the appropriate DCOM packet. The receiving system decrypts the ticket with its secret key, extracts the session key KC,S from the ticket, then decrypts and validates the authenticator. If everything checks out, the user's identity information is extracted from the ticket—principal name, domain name, and authorization data—and made accessible to the server application. All of this work is done by the Kerberos SSP; the developer of the server application doesn't have to worry about it. Although Kerberos itself doesn't directly address the problem, the information about the user that's extracted from the received ticket can eventually be used to make an authorization decision. Exactly how this is done is up to the creator of the server application. It might look up the user's name in a list of users authorized to perform some function, or it might use the authorization data to impersonate the user. In this second case, the Local Security Authority (LSA) on the server's machine constructs a security access token using the user's authorization data. Once this is completed, the server process uses this token to impersonate the user and try to access whatever resource the user is interested in. How an authorization decision is made is not within Kerberos's purview, but Kerberos does guarantee that the identity the user is claiming in this service ticket truly identifies that user. To make sure this is all clear, let me summarize why this process works. Since the service ticket the user presented was encrypted using Server S's secret key, and since only the KDC (along with Server S, of course) knows that key, this ticket must have been created by the KDC. And since the KDC will only give out service tickets to users who can prove they know the right password by correctly encrypting the preauthentication data, this user must be who she claims to be. When presented with valid authenticators, the tickets that are used by Kerberos provide reliable authentication of clients. But what about the reverse problem? You've just seen how Kerberos authenticates the client to the server, but how can the client be certain that the server is who it claims to be, too? It might be possible for an attacker to install a spurious version of Server S, then acquire sensitive information by fooling the client into thinking it was the real Server S. To prevent this, the Kerberos standard defines an option for mutual authentication, an option that should be requested by pretty much every application. Not only does the client user prove its identity to the server, but the server must also prove its identity to the client. To do this, the Kerberos SSP on the server creates a message containing the timestamp from the client's authenticator encrypted using the client/Server S session key, KC,S. When this message is received by the Kerberos SSP on the client, it can use its copy of the session key to decrypt it. If the client's Kerberos SSP finds the timestamp it just sent, it can be certain that the server knows the session key, too. And since learning the session key required decrypting the server's ticket, which required knowing the server's password, this server must be who it claims to be. Providing Data Integrity and Data Privacy All of the complexity described so far has focused on how Kerberos provides just one security service: authentication. But Kerberos can also provide data integrity and data privacy, two other useful services. Because the exchanges just described have left the client and server in possession of a shared session key, providing these additional services is straightforward. To guarantee that no attacker can modify transmitted data without being detected, the Kerberos SSP on any system that's sending data can compute a checksum on each packet it sends and transmit that checksum with the packet. The checksum value is a function of the data it's based on, so if the data is changed, the checksum must also change. But sending just a packet and a checksum isn't sufficient—an attacker could grab the packet, modify the data, recompute a new checksum on the new data, and send it on its way. To prevent this from happening, the data's sender computes the checksum on not just the message itself, but on the message and other information, then encrypts the result using the session key. By default, the checksum algorithm used in Windows 2000 Kerberos is something called HMAC (Hash-based Message Authentication Code), and the checksum is encrypted using RC4, although other options are also supported. Now, no attacker can create a valid checksum for modified data, since no attacker knows that key. The result is that the receiver of a packet can always detect any attempt to modify the contents of that packet. As always, this work is done by the Kerberos SSP—application developers need only request the service. Providing the last service, data privacy, is simple. Since the client and server share a session key, the Kerberos SSP on each one just uses this key to encrypt data it sends to the other. Note that data privacy implies data integrity, since no attacker can modify encrypted data in transit on the network without those changes being detected. An application using Kerberos isn't required to use its data integrity or data privacy services. They're typically requested through the appropriate API, and they can hurt performance. But choosing not to use these services leaves openings for attackers, so it's up to each application developer to decide whether the trade-off is worth it. Other Kerberos Topics Kerberos provides the fundamental security services required for a distributed environment: authentication, data integrity, and data privacy. But there's more to this technology. Let's look at a few advanced Kerberos issues, beginning with something called delegation. In the example described earlier, suppose the user has already authenticated herself to Server S. Server S can now impersonate the user and attempt to access something on its local system, such as a file. In this case, the access checking built into Windows 2000 will grant or deny the access based on the file's ACL. All of this works naturally if the resource being accessed is on the same machine as the server. But what if it's not? Suppose that to carry out whatever task the user is requesting, Server S must make a request to another server, Server T, running on another machine. Even though Server T's direct user will be Server S, access is being requested on behalf of the original user, not Server S. For this to work correctly, the user needs some way to pass its identity to Server S, allowing Server S to make further remote requests on its behalf. Kerberos supports this concept through delegation, as shown in Figure 5. If a client application requests it, a user's TGT and its associated session key can be passed to another server, such as Server S. (Sending just the TGT wouldn't be enough, since the associated session key is required to construct the authenticators sent along with the TGT when new tickets are requested.) Like all tickets, the TGT is encrypted, but to ensure that attackers can't steal the TGT's associated session key off the wire when it's passed from client to server, that key is sent encrypted using the session key the client shares with Server S. |
 |
| Figure 5 Kerberos Delegation |
|
The TGT passed by the client to Server S must have the FORWARDABLE flag set in its Flags field. If it does, Server S can present this TGT to a KDC and request tickets to other services even though the IP address in this TGT won't match Server S's IP address—the FORWARDABLE flag tells the KDC that it's okay to ignore this discrepancy. Also, a client can only send its TGT and associated session key to a server if that server's account is marked as trusted for delegation in this domain. It wouldn't do to allow users to delegate their identity to just any server they run across.
To see how this all works, suppose the client passes its TGT and associated session key to Server S with the FORWARDABLE flag set. If Server S needs to access Server T on the client user's behalf, it can present this TGT along with a valid authenticator to the KDC, requesting a new ticket for Server T. This new ticket will contain the user's identity, just like the original ticket, but will be encrypted using Server T's password. When Server S presents this new ticket to Server T, again with a valid authenticator, Server T will behave as though it is receiving a request directly from the client. Kerberos also allows authentication between clients and servers in different domains, although the process is a bit more complex than what you've seen so far. To authenticate itself to any server application, no matter what domain that server is in, a user must acquire a ticket to that server. But only a KDC in the same domain as the target server can issue that ticket, since only it knows that server's password. If a user wants to authenticate herself to a server in a different domain, then she must request a ticket to that server from a KDC in the foreign domain. And as is always the case, requesting a ticket from a KDC requires presenting a TGT to that server. The fundamental problem is for the user to acquire a TGT to the KDC in the foreign domain. Once she has this, she can request and use a ticket to the target server in the normal way. For this to be possible, the two domains must have a trust relationship between them. When a trust relationship is created between two Windows 2000 domains, a password is also created that is known only to those two domains. As is described next, this shared password can be used to encrypt a ticket that's passed between the two domains. Figure 6 shows how the process works (and although they have been omitted from the diagram for simplicity, authenticators and session keys are still used as described earlier). Suppose a user in the domain acct.acme.com wants to access Server Q in the sales.acme.com domain. The Kerberos SSP on the client system begins by presenting the user's TGT to the KDC in the user's own domain, acct.acme.com, requesting a TGT to the KDC in sales.acme.com. The acct.acme.com domain's KDC responds by sending back a TGT that the client can use to request tickets from the KDC in the sales.acme.com domain. This ticket is not encrypted using the password of this domain's KDC, as it normally would be. Instead, it's encrypted using the password shared between the domains acct.acme.com and sales.acme.com, designated KX in Figure 6. |
 |
| Figure 6 Authenticating Across Domains |
|
Once it has this TGT, the client's Kerberos SSP then presents it to the KDC in the domain sales.acme.com, requesting a ticket for Server Q. The KDC in sales.acme.com decrypts the TGT presented by the client using KX, the password it shares with acct.acme.com's KDC. If the TGT is valid, this KDC then looks up Server Q's password in its Active Directory database and uses it to build a ticket for Server Q. It then sends this ticket back to the client, which can present it to Server Q.
Despite the apparent complexity of Figure 6, the mechanics of using Kerberos between domains are simple. All that's required is adding the single extra step of getting a TGT for a foreign domain's KDC (and again, this is done automatically by the Kerberos SSP—application developers don't have to worry about it). But think about what the KDC in sales.acme.com is implicitly assuming in this example: it's trusting the KDC in acct.acme.com not to give out TGTs to it without first validating the user's identity. In other words, by accepting a TGT encrypted with the key it shares with acct.acme.com, sales.acme.com's KDC is trusting the KDC in acct.acme.com to behave correctly. For cross-domain authentication to work, the two domains involved must trust each other. Kerberos also supports transitive trust, which is a fancy name for a simple idea. The idea is that if one Windows 2000 domain trusts a second domain, and if that second domain trusts a third domain, then there is automatically a trust relationship between the first domain and the third domain. In Windows 2000, every domain in a domain tree or forest has a two-way trust relationship with every other domain in that tree or forest. Transitive trust ensures that domains only need to share a password with the domains immediately above and below them in the domain hierarchy—Kerberos takes care of the rest. Kerberos was originally designed to require only secret key encryption. Today, there is also an IETF specification for using public key technology to acquire a Kerberos TGT, and Windows 2000 supports this option. This approach allows using smart cards, which eliminates one of the potential weaknesses of Kerberos: its reliance on passwords chosen by users. In standard Kerberos, if I can guess or steal your password, I can log in as you. With smart card-based login, this is no longer true. Instead, I cannot pretend to be you without both having your smart card in my possession and knowing the card's PIN. The protocol for using public key technology to acquire a TGT is known as PKINIT, and describing how it works is beyond the scope of this article. Suffice it to say that you're likely to be carrying smart cards within a couple of years, and that this innovation will significantly enhance the security of Windows 2000-based distributed environments. Why Kerberos is a Good Thing There's one last point about Kerberos that's worth addressing: why did Microsoft bother with it? In previous versions of Windows NT, network authentication was handled by NTLM. Why make a change? How is Kerberos better than NTLM? There are several answers. First, as you've already seen, Kerberos provides several features that aren't available in NTLM. Delegation and mutual authentication are both available with Kerberos, but neither is possible with NTLM today. Also, Kerberos is typically faster than NTLM, since each NTLM client authentication requires a server to contact a domain controller. In Kerberos, by contrast, a client can supply the same ticket over and over, and the server can use just that ticket to authenticate the user. There's no need for the server to contact a domain controller each time a user needs to be authenticated. And finally, Kerberos is a multivendor standard, so it allows secure interoperability and the potential for single sign-on between the Microsoft world and other vendor environments. Any way you look it, Kerberos qualifies as progress. It's nice to see this powerful, secure, but long-neglected protocol move into the limelight. After years of languishing in relative obscurity, Kerberos is about to go mainstream. |
 For related information see: Kerberos Components in Windows 2000 at http://msdn.microsoft.com/library/psdk/secspi/aboutsspi_1lm8.htm. Also check http://msdn.microsoft.com for daily updates on developer programs, resources and events. |
|
From the August 1999 issue of Microsoft Systems Journal.
|
