Applying Secure Communication

[Previous] [Next]

Deciding how to secure the communication of your service can be tough, so you should make this decision armed with as much information as you can get. Here are some questions you should ask yourself:

1. Is it important that I can authenticate my client to a Windows domain account?
2. Will my client be in my domain, outside of my domain (perhaps via the Internet), or both?
3. Will I be interoperating with non-Windows clients?

If your authentication needs will boil down to a Windows token (which is great for impersonation and access control), you will most likely want to use NTLM or Kerberos. However, you could use SSL and allow the system to maintain a mapping of certificates to domain accounts. This would require extra maintenance, as I have described earlier.

NTLM and Kerberos authenticate to a domain naturally. So if your answer to the first question is "yes," you need additional incentive to use SSL and certificates.

If your client is going to be in your domain, your options really open up. You can use named pipes, which automatically use Kerberos or NTLM authentication and ease this process greatly. Of course, pipes have scalability issues, and if you are connecting to thousands of clients, you will most likely want to use TCP/IP with sockets.

Even so, clients that are guaranteed to be in your domain make coding easy. You can set up your server to use the Negotiate security package, and your clients can use the most appropriate package for them. Windows 2000 clients will use Kerberos, and all others will most likely use NTLM. Using these options, you can design a clean, secure environment that is relatively easy to implement.

But what happens if your client is going to be outside of your domain? If you are not concerned with gaining a Windows token, clients outside of your domain might as well use SSL and certificates. If you do want a token for your user, on the server side you've got some issues to contend with where impersonation is concerned.

If the client is outside of your domain, you can assume that the client is able to communicate with your server. This means you can consider the NTLM protocol. The client will pass its username, password, and the server's domain into AcquireCredentialsHandle. This information is communicated to the server. Since the client communicates only with the server, it is not necessary for the client to have access to the DC, and so the client can be outside of the domain. Meanwhile, the server is inside your domain, has access to the DC, and can get a token for your client. This is pretty nifty.

With Kerberos, dealing with a client outside of your domain is not this easy. Much of the authentication process involves client communication with the KDC. This is great in terms of efficiency but can complicate communication with clients outside of your domain. So NTLM looks attractive once again for authentication because it's relatively easy to use outside of your domain.

SSL can be used to achieve a token on your server side, and it requires the client to communicate only with the server, but it carries with it the baggage of certificate management. Where do you get your certificates? Are you paying for them or issuing them yourself? If you are issuing them, will it be difficult to acquire trust on the client side? If not, do you and your client trust the same root CAs? Finally, if a token is your goal, you must either manage the certificate mapping in Active Directory or use certificates issued by an enterprise CA running Microsoft Certificate Services (which may or may not meet your needs in other respects). And what about the issue of interoperability with other operating systems? Well, SSL shines in this manner. The SSL and certificates scale well and are implemented on other operating systems. Our implementation interoperates great! But SSL comes with some limitations, which you know of.

You do have some other options though. The Kerberos SSP is interoperable with the UNIX Generic Security Service (GSS) library. You must handle some extra details when using EncryptMessage and DecryptMessage. However, this interoperability makes it reasonable for you to create a UNIX client that communicates using Kerberos with your Windows server. The GSS and interoperability is covered in detail in the Platform SDK documentation. The Platform SDK also includes a complete GSS sample.

Encryption Is Not Equal to Security

Once you have mastered the SSPI and other features provided by Windows, you might feel that your server is secure. But it might not necessarily be.

Kerberos and NTLM make tight security easier because they use symmetric encryption based on a user's password. Once your certificate is authenticated, you can be reasonably sure that you are communicating with an entity that knows the password, especially when you use Kerberos. (However, passwords are not "strong" security in that they can be "known" or derived more simply than a private key can. So password security is a major concern.)

SSL is nowhere near as simple as NTLM and Kerberos. Certificates do not naturally map to a user account in a domain, and they do not directly map to a known secret as simple as a password. So here is the question that you have to constantly consider: Now that I know I am communicating securely with the holder of this certificate's matching private key, how do I know who the holder is?

Public key encryption and decryption have given us powerful tools to ensure that we are communicating with one entity and one entity only. But the question of whether to trust that entity in the first place is still open. Here is the catch: all the information in a certificate is public. So what information are you checking to ensure the certificate in question belongs to the entity that you want to connect to?

• Are you relying on the common name in the certificate? Can someone else use another CA to create a certificate with the same common name?
• Are you relying on the common name matching a URL? Is it possible for someone to create another certificate that matches the same URL?

The answer to all of these questions is yes, but knowing this information doesn't make your authentication process any more secure. So it is necessary for you to know extra information about the CA that issued the certificate:

• What information does the CA guarantee to be unique?
• How much research does the CA do before granting a certificate?

Another consideration is how you should communicate these questions to the user. How can you do this in a way that is not so confusing as to cause the user to always give up and trust everything and everyone?

The challenges posed by these questions are serious but not insurmountable, though no single solution has arisen that solves these problems for every scenario. With proper consideration, you can solve these problems so that your specific needs are met. In short, public key infrastructure is powerful, and if you choose to use it, you can do it in a secure way. You just have to be able to answer all the questions I just posed for your software. Figuring out the answers to these questions is the challenge of secure programming and the reason that writing secure software is so incredibly rewarding.