Why X.509 Is Popular

The X.500 family of standards has been around for quite some time. Still, not many software products used these standards until the explosion of interest in the Web. The Secure Sockets Layer (SSL) is widely relied upon for secure communications across the Web. A commonly used implementation of SSL is delivered by RSA, Inc., now part of Security Dynamics. The founders of RSA (Rivest, Shamir, and Adelman) were some of the original researchers in public-key technology. Consequently, it is not surprising that SSL is based upon public-key techniques and X.509 certificates. Web browsers and servers that carry out secure communications across the Internet primarily depend upon SSL for security services.

Like GSSAPI in Kerberos V5, SSL is available separately as a set of library routines from RSA. This means that arbitrary applications written by vendors can be enabled to take advantage of SSL features for secure distributed communications. Because the UNIX sockets interface is a common programming abstraction for thousands of programmers, you can reasonably assume that SSL will be a popular tool for distributed security in many products to come. Higher level programming interfaces, such as Microsoft’s CryptoAPI and Intel’s Common Data Security Architecture (CDSA), also fit nicely with the X.509 and SSL approaches.

Comments on X.509 Security

The weakest component in the X.509 approach is still the reusable password. If you have a Web browser that supports certificates, you already know that the certificates are stored on your system’s disk. Before writing the certificate to disk the system first encrypts it using a password hash. The password is reusable and chosen by you when configuring your browser. For unattended operation of servers that rely on certificates, a data store is also needed for the server’s secret key or keys. In this case, a password chosen by the system administrator is the basis for the hashed key used to encrypt the server’s secret key. If an adversary can capture the encrypted value, an offline password cracking attack can be undertaken.

It is practically impossible to break commercially available public-key implementations, assuming sufficient key lengths and discarding experienced cryptanalysis. However, the system is still threatened because if the secret key of a key pair is disclosed, an attacker can impersonate the certificate’s owner or decrypt private messages. Because the secret is protected by the fallible reusable password, we have sufficient reason for concern.

Note also that with respect to identity within the context of a local operating system, X.509 certificates are not replacements for UIDs and GIDs. Like Kerberos, X.500 and X.509 introduce their own subjects and objects, and even bring along a separate access control mechanism. It’s not hard to find UNIX network applications that are enabled to work with Kerberos. Discovering a freely available or commercial version of one of these applications that has been modified to use X.509 is less likely today but should change in the near future. Given the widespread interest in certificate-based authentication, it is advisable for operating system vendors to support integrated login with X.509.

Some important concepts can be summarized from the previous discussions on authentication:

•  Authentication involves proving knowledge of a shared secret.

•  Reusable passwords are not the most reliable value for authenticating users.

•  A shared session key, regardless of how it is obtained, can be used for secure communications between parties. The session key can also be used to establish the authenticity of the parties.

•  A session key that is used only once is very desirable because it is highly resistant to cryptanalytic attacks.

•  An authentication server can be used to distribute shared secrets to parties, and such a server is an administrative necessity in large networks.

•  Frameworks such as Kerberos and X.509 do not replace the subjects and objects in an operating system, although they can be used to augment the I&A process.

Now that you understand some alternatives for secure authentication and communication, it’s time to make some additional recommendations for improving login security at your site.

As you have seen from the previous discussions, traditional I&A security is weak in a number of ways. Intrusion detection products are designed to assist by monitoring the system for password attacks and other suspicious behaviors. Even if you have an authentication server such as Kerberos, RADIUS (Rigney et. al. 1997), or TACACS (Finseth 1993), you will want to add an IDS to monitor the authentication server. Weaknesses in Kerberos implementations or protocols (some identified earlier) as well as published exploits for RADIUS implementations should encourage you to monitor the activities of your authentication servers with an IDS. After all, I&A is the first step in securely accessing your system.

Ideas for Improving I&A Security

Now that you know about weaknesses of reusable password authentication, it’s time to check into alternatives. In this section, you learn about stronger techniques for authenticating users and other entities in networked environments. You should know in advance that even though you can eliminate some problems with better I&A tools, you will still need other security products, such as IDSs, to complete your solution.