One of the key issues in security is verifying identities. After such verification, a guard at a gate or a computer server can check to see what resources that person is allowed access to. This process is called authentication, and Windows 2000 provides for some very flexible options, including plugging your own custom authentication scheme into a network. The key to this flexibility is the Security Support Provider Interface, or SSPI.
But before we delve into the details of how this all works, let's take a look at how authentication works. Before a gatekeeper grants access to resources, there must be some way to verify identity. In many common situations some kind of authority figure is consulted. For example, when I go to a bank to cash a check, the bank generally relies on the State of Alaska to have properly verified my identity before granting me the drivers license I present as proof of my identity. Similarly, when I submit to a retinal scan, the system compares what it sees in my eye to a database that it trusts to contain records only for people who have some kind of access to the protected resources. There are obviously other issues to consider here, such as the integrity of the database and the security of the lines of communication used, but the point is that some kind of authority is consulted.
The complexity of this authentication process depends on the importance and sensitivity of the resources it is protecting. Naturally, I want the bank to check drivers license, passport, fingerprints, and DNA when someone tries to access my account, but when I want to get at my money it needs to be as simple as possible. The design of authentication systems consists of a series of tradeoffs like these.
Authenticating a client for secure network communication follows a common pattern, although the precise steps depend on the way the parties have agreed to handle such matters. The transaction typically begins by the client and system exchanging bits back and forth, kind of an electronic introduction. The server consults a trusted authority to check out the user and whether the user has access rights. Once they have established a trusted relationship, the client and server can begin exchanging information, reasonably confident that they know who the other party is.
It sounds simple enough, but next we need to consider the communications medium being used, such as a TCP/IP network. Assuming that the communication is going over the public Internet, any number of routers and intermediate systems must handle the data packets, opening the communication to modification by malicious third parties. But the client and server can agree to encrypt the data, using any of the many encryption methods available today. But such systems depend on at least one of the keys used for encryption to be safe and secure from prying eyes, and then it becomes a complex problem making sure that the keys are not compromised. Another option is protecting communications using a Message Authentication Code, which doesn't prevent the contents from prying eyes but does prevent its modification. The checksum must be encrypted, but this frequently is far more efficient than encrypting the contents of an entire message. You can easily see how a simple request for information from a server can grow into a very complex transaction.
Security Protocols
The logistics and details of how all these steps are handled are determined by the security protocol in use on the network. Both parties to a communication must agree to the protocol used, otherwise no communication will happen. Usually, this means that the server mandates a protocol; if the client can't comply, it won't have access to the network resources.
There are many protocols available for this, but in Windows there are a few in common use. Windows NT primarily used the Windows NT LAN Manager (NTLM) challenge-response protocol, while the default protocol in Windows 2000 is Kerberos. Kerberos, named after the multi-headed dog that guards the gates of hell, is an Internet standard that Microsoft almost fully implemented. (The company used an undefined field, which keeps some Kerberos implementations from communicating with Windows.) There are many other protocols, such as the Secure Sockets Layer (SSL) commonly used for Web applications.
The authentication process is quite different between NTLM and Kerberos, taking one example, as shown in the figure. At a high level in NTLM, a communication takes place between the client and server, then the server checks with the authority to authenticate the client. But in Kerberos, the client first checks in with the authority, obtains a ticket, and uses that to prove identity. Kerberos supports caching tickets, so an entire communication could occur with but a single interaction with the authority. NTLM doesn't support caching, so every request from the client results in another request to the authority. And the differences go on.
Figure 1. Different protocols can require different routes to authentication.
|
|
Home:
Software Development:
Development Tools & Environments:
Windows
