The Battle Of The Logon Titans

By Robert Moskowitz Is your IS department's modus operandi one size fits all? You can see it in everything you do. There's one operating system on every desktop and everyone in the company uses the same word processor, spreadsheet, graphics and e-mail program to smooth internal communications--to say nothing about easing helpdesk support and training. We all realize that such an approach has its downside for our users, but isn't it nice to have a life and not spend all of our time resolving compatibility issues. However, we're still struggling in the logon arena, and management is not pleased. With so much attention being paid to logons, the heat is on. You will be called upon for a single logon solution--and if it's not based on digital certificates, you'll be missing the opportunity of a lifeti me.

The Single Logon Challenge The number of logins our users are faced with is daunting. Over the years, that number has grown from a few for the MVS mainframes and a network server or two to dozens for different prompts, IDs and password formats. In addition, users are presented with different logon paradigms. They cannot use consistent user IDs, let alone passwords. And some products require password revalidation if the session is idle for some period, and each password has a different expiration cycle.

A number of enticing approaches to the single logon approach exists. Scripting- and Kerberos-based systems have been the standard for a number of years. Management has seen these and knows you can fix the logon problem in your company. Perhaps you've even had some success with a single logon product. However, I would like to point out rule No. 6 of RFC 1925 (also known as The Twelve Networking Truths): "It is easier to move a pr oblem around than it is to solve it."

When adding a single logon product to our corporate offerings, we take on a major responsibility. We must maintain the synchronization of the user applications with the logon system while allowing those applications to evolve as required by the user community. Of course, your company is just a small part of the total user base for a commercial application. So, you'll have to bear with upgrade delays as you plan the impact of those applications on your single logon system.

Moving Targets RFC 1925 reminds us of yet another truth to remember when implementing technologies like single logon: "It is always more complicated than you think." A number of pressures work against the success of the single logon. For instance, a significant portion of this problem comes from the constant addition of new applications created by authors who have never heard of single logon or who believe they have a better idea.

The other portion of the problem is the continued develo pment of two critical authentication technologies: Kerberos and digital certificates. Kerberos offers a low overhead for authentication, but faces major security-breach risks and scaling challenges. Digital certificates are the mirror image. They have a very low security risk with excellent scaling, but have a much higher overhead for authentication. The choice between these two is further complicated by Microsoft's selection of Kerberos for NT 5 and the SSL's (Secure Sockets Layer) use of digital certificates. If these two technologies would only stay buried within their respective applications, they would have no impact on our IS modus operandi of one size fits all, and we could stumble along with single logon.

Drawing the Lines Kerberos and digital certificates in a PKI (public key infrastructure) are the two tumultuous titans in the single sign-on saga. A 1993 effort by MIT and Digital to bring the two groups together imploded. Since then, the use of these technologies has grown. Kerberos has b een more successful in reducing the number of logons users need, while certificate-based systems have so far only added to the number of user logons. This situation is starting to change, however, because certificate-based single logon systems are emerging.

Another significant difference between these two approaches lies in the fact that applications are built to use certificates, whereas shims must be added to support Kerberos. A number of Unix subsystems, like telnet and RLOGIN, are commonly available with Kerberos support, but the more common LAN applications, like POP mail clients, typically do not support Kerberos. Putting it simply, this means that the older style applications might be amenable to Kerberos, but the newer applications are coming with certificate support built in. This distinction will further blur with the release of NT 5. At that point, it appears to be a lose-lose situation for both the support staff and the users.

Choosing Wisely The penchant for IS to select just one me thodology and shoehorn all users into it can have some expensive repercussions when applied to application logins. Many systems have no methodology, but Kerberized systems can be expensive to change over to certificate-based systems and vice versa--if that's even possible. Usually, it isn't. The informed organization will work at taking advantage of the strengths of both, making them work together. Digital certificates are the most powerful method for identifying people and systems. And yes, a CA (certificate authority) is a safer registry--a break-in to a Kerberos key center compromises all user identities. But, a Kerberos system can be designed to use a CA. The simple joining of these two camps produces a powerful logon environment: It delivers the strengths of both methodologies and lessens their individual weaknesses.

A certificate-based Kerberos login (referred to as PKINIT or public key initialization) eliminates the largest risk in a Kerberos system by using the private key on the user's system with the public certificate on the CA instead of the user's secret key on the Kerberos key server. If you're willing to put the user's private key on the CA, this makes the user's digital certificates portable. This facilitates roaming by the users--a difficult process for most certificate-based systems. This may not be an acceptable risk because stolen certificates are more valuable (they have a stronger basis in our legal system). With both a Kerberos ticket and a digital certificate, your application developers can select the most cost-effective approach--a substantial issue for the developers.

In general, single logon has been, at best, a poorly realized dream for most of us. Those that have tackled it have added to their support costs or to their system's complexity. But all that just might change this year. By deploying a digital certificate environment and joining Kerberos to it, you can create a powerful framework for single logon. It seems that logon titans are much like heads: Two often are better th an one.

Robert Moskowitz is a software systems specialist at Chrysler Corp., Detroit, and a member of the Internet Architecture Board (IAB). He can be reached at rgm@htt-consult.com.