Our Three Competitors

There are probably dozens of security techniques. Why did I pick SSH, SSL, and Kerberos? My primary reason is that I kept getting these confused myself. I hoped that by doing some real research on the topic for you, my loyal reader, I would finally get the terms straight in my head. And as it turns out, while I've learned a lot about these various protocols, I find that the issues aren't nearly as clear-cut as I would have liked.

About the only thing these different techniques have in common is that they all can use some variant of public key cryptography. The way this works is that there are two keys, the public key and the private key (together, these are called a digital key pair). The public key is used to encode messages. Once a message is encoded, only the private key can decode them. You keep the private key secure and give the public key to the rest of the world. They can then encrypt messages with reasonable (though not 100%) assurance that nobody besides you can read them.

SSH

SSH is perhaps the simplest of the three. SSH is a very flexible protocol whose purpose is to set up an encrypted tunnel between one machine and another. With SSH, you can use either a simple user ID and password or a digital key pair. SSH was originally designed to support secure versions of console login (Telnet) and file transfer (FTP). The SSH software by definition supports these two functions. Additionally, once an SSH tunnel is created, you can route all other IP-based applications through it, including HTTP. So, in theory, SSH supports any application.

SSH has two primary versions right now, SSH-1 and SSH-2. At this time, SSH-2 is not as widely supported as SSH-1, and the two are incompatible. While SSH-2 provides a number of additional features and is a very powerful evolutionary step from SSH-1, the lack of universal support can be a problem. The good news is that a couple of the major open source products, OpenSSH and Eclipse, have announced support for SSH-2.

The biggest problem with SSH is that it does not truly authenticate the host. This is a concept we usually don't think about, but as important as it is to make sure that the client is who he says he is, the same holds true for the server. Otherwise, you can be getting bogus data; more importantly, you can find yourself entering sensitive information into a spoofed server. SSH bypasses this sort of security, and because no certificates are involved, once an SSH relationship has been breached, there's no way to revoke that authority.

SSL

Netscape developed the proprietary SSL protocol specifically to secure HTTP communications. SSL uses digital certificates that adhere to the X.509 standard to verify the communication. Unlike SSH and Kerberos, X.509 is the only certification method used for SSL. You can either use a single certificate to validate the server or use an optional second certificate to validate the client as well. The single-certificate method is the most widely used method of secure communications for WWW communications; this is what you use when you access a URL that starts with "https" rather than "http."
SSL is a well-established protocol. It has an open source version, OpenSSL, and it even has an IETF spin-off, Transport Layer Security (TLS), which you can read about as RFC 2246). TLS is the open standard version of SSL3, which removes the minor quibble that SSL was a "Netscape thing." The biggest downside to SSL is that it requires a third-party certificate authentication system, such as the VeriSign Certificate Authority, to verify that the certificate is valid. That means you are at their mercy when it comes to server availability and certificate verification. You may recall that the Verisign certificate itself expired back in January, causing a bit of trouble for people using SSL.

You'll often hear about "self-signed" certificates, which essentially bypass the server authentication. They set up a secure tunnel, but you really don't know who is on the other end. From that standpoint, a self-signed SSL certificate is really no more secure than an SSH connection. However, since they're built in to most browsers, SSL connections are inherently easier to set up than SSH connections.

Kerberos

Kerberos is a protocol originally invented at MIT, and in other MC Mag Online articles, Carol Woodbury has done an excellent job of explaining how Kerberos works and how to plan for single sign-on (look for more from Carol about single sign-on next week). Kerberos is fast becoming a de facto industry standard for single sign-on; SSH and SSL don't have the ability to provide the single sign-on capabilities of Kerberos.

Kerberos has many interesting features, but one of the most important is the fact that it requires its own certification machine called a Key Distribution Center (KDC). This replaces the public key infrastructure of the X.509 certificates. On the plus side, it means you don't have to rely on (and pay) a company like Verisign for your security. On the minus side, it means your network is very reliant upon the machine that houses the KDC. If that machine goes down, no service that relies on Kerberos authentication will work.

Even more important in my opinion is the fact that access to my iSeries is now controlled not by the iSeries but by another machine, the KDC. In the brave new world of single sign-on, I need only sign on to my workstation to gain full access to all of my resources in the network, including my user profile on the iSeries. Thus, if someone breaks the password protection of my desktop (or simply walks over to my machine while I'm logged in), he now can get into my iSeries data as well. And if someone manages to get into my KDC, then he literally has the keys to the kingdom. That seems like an awful lot of power to be consolidated in a single point.

Interestingly, with Kerberos V5, the concept of pre-authentication comes into play. Pre-authentication is how the client and server recognize one another. Currently, this uses a public key and a timestamp (the client has a short period of time, usually five minutes, to determine the appropriate response). While this seems reasonable, there's nothing stopping a hacker from sniffing that conversation and then applying brute force to the intercepted key. It make take longer than five minutes, but that's OK. The cracker can just save the passphrase for the next time. Kerberos V5 also supports a "pluggable" authentication module, which means that stricter methods of authentication can be employed, but that seems to be rather rare at this time.

Excellent! Now I Know Everything! Right?

Unfortunately, even if this little article brought some light into the darkened corners of security, it's hardly even a scratch. You may come across dozens of other protocols as you do your own research. Here are some terms:

NTLM

NT LAN Manager authentication (an old Microsoft standard) doesn't even provide encrypted sessions, but it's better than nothing.

SRP and SPEKE

As it turns out, Kerberos isn't really a strong protocol. Those who claim to know these things say Kerberos V4 is a "weak" protocol, and Kerberos V5, while stronger, only ranks as a "pseudo-strong" method. In either case, someone with a little access they shouldn't have and some brute force processing power could conceivably break your keys and emulate you.

Protocols exist that are mathematically proven to be a lot stronger. Well, I shouldn't say that. I should say that I can't see any fault in the mathematical proofs, but IANAM (I am not a mathematician). The protocols in question are derived from theorems having to do with something called Zero Knowledge Protocols (ZKPs). Secure Remote Password (SRP) was developed at Stanford in the late 90s. However, it seems to not have gained much popular acceptance. Another version, Simple Password-authenticated Exponential Key Exchange (SPEKE), has commercial life at Phoenix Technologies.

SPEKE allows you to have very secure sessions with simple passwords, avoiding nearly all the problems of the other protocols. Simple passwords are important because so-called "strong" passwords (such as r#hhsj!633f) are difficult to remember and thus are subject to the "Post-it security hole"; users tend to write the password on a Post-it or some other scrap of paper and then stick it somewhere very near their terminal. This simple human engineering problem can defeat the strongest of security protocols.

So Kerberos Is the Winner?

Whether Kerberos is the winner depends on your definition of the word "winner." The biggest strength of Kerberos (single sign-on) also contains its largest potential for abuse. This use of Kerberos blurs the distinction between authentication and authorization, two very different issues, and in my mind has a potential for disastrous results.

Authentication and Authorization

Authentication simply means that you are who you say you are. No more, no less. So it allows me to log on to my Windows machine. Now, let's say someone manages to get my Windows password. No problem, they can only sign on to the LAN; they'll still need an OS/400 user profile and password to get at anything on the iSeries.

However, with single sign-on, that one password also provides authorization. It in fact opens the doors to everything that I am authorized to according to the Kerberos server. And while this may seem to be a semantic distinction, it becomes more problematic when one realizes that the Kerberos technology can be compromised.

Avoiding Problems

You can easily avoid some of the more serious problems that could occur from this weakness. For example, never provide a single sign-on capability for security profiles such as QSECOFR. In fact, I would highly recommend never allowing the KDC to authenticate any user profile having *ALLOBJ or similar wide-ranging rights.

Incomplete Support

Another issue is the fact that not everybody supports Kerberos right now. I don't have up-to-date information on everything, but as far as I am able to discern, not all JDBC or ODBC drivers support Kerberos. Thus, you may well be able to bypass the logon, but then you'll need some other way to access the database, and now you're back to the traditional design problems of either storing passwords in your application or accessing the database through a different user profile. This nullifies the benefits of the single sign-on.

Not only that, but if your applications are designed to use Kerberos, then all users will require Kerberos identities, and that's probably not realistic for true Internet applications. It's probably not even a good idea for extranet applications that go to vendors and clients.

Use the Right Tool for the Right Job

It's clear that Kerberos is not right for everything. We've been arguing the "right tool for the right job" issue on the mailing lists lately for everything from SQL vs. native I/O to Java vs. RPG. In this case, it means using the security mechanism that is appropriate for the job at hand. Kerberos and single sign-on make sense for intranet applications and perhaps even for Web access to company applications by mobile users. But for general Web access required by extranet and Internet applications, it's more appropriate to use the standard SSL techniques and the public key infrastructure that's already in place. Finally, for mission-critical connections between two machines for administrative tasks like remote backup and problem diagnosis, it makes more sense to use SSH because that protocol does not rely on a third machine. If the problem is that your machine can't communicate to the KDC and at the same time you can't sign on without the KDC, then you're going to have a hard time fixing the problem.

So Back to the Original Issue

My most nagging objection to Kerberos and single sign-on is that access to my iSeries is no longer handled by my iSeries. The KDC has carte blanche to provide access to any machine that's been turned over to it, and since users are always demanding more convenience, it's inevitable that all of my production machines will be turned over.

Thus, in order to allow a user to log on once and access my entire network, I have to turn over access to my most sensitive data to a security mechanism that is ultimately hackable. As I explained a little earlier, the time-based pre-authentication method employed by Kerberos V5 is vulnerable to brute force attacks by a determined hacker. However, Kerberos V5 looks like it can be extended to take advantage of some of the more secure handshake technologies.

So there are two conclusions to be drawn. First, the old adage of the right tool for the right job holds very strongly here. Your overall security environment may be an amalgam of two or three different security approaches for different classes of users. Second, Kerberos may provide some convenience for your end users, but the price for such convenience is extra vigilance, starting with determining which user profiles are really candidates for single sign-on.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web and Eclipse: Step by Step, with WDSc: Step by Step coming out this September. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..