Chapter 5. Identification And Authentication

At a Glance

Identification actually comprises three concepts. Strictly speaking, identification is the associating of an identity with a subject. Authentication is establishing the validity of an identity. Authorization is associating rights or privileges with a subject. This chapter is concerned primarily with the first two concepts. Identification and authentication may be performed solely by the workstation that a subject is using, or may involve a network-based authentication system in which user identities are stored by a central server and shared by groups of client workstations.

Identification Techniques

Computers use a variety of user identification systems. The simplest are based on usernames and passwords; others are based on special-purpose hardware that can measure unique distinguishing characteristics of different human beings. Finally, there are systems that are based on public-key cryptography.

No identification techniques are foolproof. Fortunately, most of them don’t have to be. The goal of most identification systems isn’t to eliminate the possibility of impersonation, but to reduce to acceptable levels the risk of impersonation and the resulting losses. Another important goal of identification systems is to quantify the amount of risk that remains once the system has been deployed: quantifying the amount of residual risk allows an organization to make decisions about policies, the need or desirability of alternative identification systems, and even the amount of insurance coverage necessary to protect against the remaining amount of fraud.

Physical Identification

Fly to an international airport, flash two pieces of plastic, and you can drive away with a brand new car worth more than $20,000. The only assurance the car rental agency has that you will return its automobile is your word—and the knowledge that if you break your word, they can destroy your credit rating and possibly have you thrown in jail.

Your word wouldn’t mean much to the rental agency if they didn’t know who you were. It’s your driver’s license or passport and credit card, combined with a worldwide computer network, that allows the rental agency to determine in seconds if your credit card has been reported stolen, and that gives the firm and its insurance company the willingness to trust you.

The key features of physical identification are based on the design of identification documents. A passport is a good identification document because it contains information that can be verified physically (sex, height, weight, age, photograph, signature), is difficult to forge, is resistant to tampering and easily shows tampering attempts, and is issued by a reliable and reputable authority that takes care to verify the subject’s identity before issuing the document. On the other hand, a paper club membership card has none of these features.

Computer-Based Identification Techniques

For more than fifty years, usernames and passwords have been a part of large-scale computer systems. Even personal computers, which lacked passwords for the first two decades of their existence, now come equipped with software that can control access using usernames and passwords. There is a key difference that separates username/password systems from the document-based systems discussed earlier in this chapter. Whereas most identification documents are printed with the true name of the individual being identified, username/ password based systems are only interested in establishing that the person who is sitting at the keyboard is the authorized user of a particular account. Traditional document-based systems concern themselves with absolute identification, whereas username/password systems are concerned with relative identification or the continuity of identification. Absolute identification is an extraordinarily difficult task for the typical computer system to perform. Instead, a plethora of relative identification systems have been fielded. Computer security professionals usually describe these systems as relying on “something that you know,” “something that you have,” or “something that you are.” The following sections describe these three traditional approaches, as well as a newer one: “someplace where you are.”

Password-based systems: something that you know

The earliest digital identification systems were based on passwords. Every user of the system is assigned a username and a password; to “prove” your identity to the computer, you simply type your password. If the password that you type matches the password that is stored on the computer, then the assumption is that you must be who you claim to be.

Because they are simple to use and require no special hardware, passwords continue to be the most popular authentication system used in the world today. As a result of this popularity, most of us now have dozens of passwords that we need to remember on an almost daily basis, including PINs (personal identification numbers) or passwords for accessing ATM cards, long-distance calling cards, voice-mail systems, and answering machines, unlocking cell phones, unlocking desktop computers, accessing dialup Internet service providers, downloading electronic mail, and accessing web sites. There are several problems with passwords, some insurmountable:

• Passwords must be distributed to users. Some systems use default passwords or allow the first user to set a password, but defaults are often left unchanged and the first user may not be the authorized user.

• Passwords can be intercepted when sent to a remote computer. Encryption can lessen this risk, but there is no way to encrypt the PIN a person types at an ATM so that it can’t be deciphered by someone looking over his or her shoulder.

• Good passwords are easy to forget, which leads people to write them down, use the same password for many uses, set up simpler second-stage password reminders, or choose bad passwords that are easy to guess.

• Passwords can be shared, which may allow unauthorized people to use resources they shouldn’t.

Physical tokens: something that you have

Another way that people can authenticate their identities is through the use of tokens— physical objects whose possession somehow proves identity.

Door keys have been used for centuries as physical access tokens; in many modern buildings, metal keys are supplemented with either magnetic or radio-frequency-based access card systems. Access card systems are superior to metal-key-based systems because every card can have a unique number that is tied to an identity. The system, in turn, has a list of the cards authorized to open various doors. Time-based restrictions can be added as well, so that a low-level clerk’s card can’t be used to gain access to an office after-hours.

Token-based systems tend to be self-policing: users quickly report cards that are lost or stolen because they need their cards to gain access; when a card is reported missing, that card can be deactivated and a new card issued to the holder. This is an improvement over a keypad-based system, where individuals can share their PIN codes without losing their own access.

As with passwords, tokens have problems as well:

• The token doesn’t really “prove” who you are. Anybody who has physical possession of the token can gain access to the restricted area.

• If a person loses a token, that person cannot enter the restricted area, even though that person’s identity hasn’t changed.

• Some tokens are easily copied or forged.

Token-based systems don’t really authorize or identify individuals: they authorize the tokens. This is especially a problem when a token is stolen. For this reason, in high-security applications token systems are frequently combined with some other means of identification: this is often referred to as two-factor authentication. For instance, to gain access to a room or a computer, you might need to both present a token and type an authorization code. This is the technique used by automatic teller machines (ATMs) to identify bank account holders.

Biometrics: something that you are

A third technique becoming more commonly used by computers to determine a person’s identity is to make a physical measurement of the person and compare the measurement with a profile that has been previously recorded. This technique is called a biometric, because it is based on measuring something about a living person. Many kinds of biometrics are possible, including images of a person’s face, retina, or iris, fingerprints, footprints, or hand geometry, voice prints, handwriting, or typing characteristics, and DNA patterns.

Biometric techniques can be used for both ongoing identification and absolute identification. Using these techniques for ongoing identification is the simplest approach: the first time the user accesses the system, his biometric information is recorded. On subsequent accesses, the new biometric is compared with the stored record. To use biometrics for absolute identification, it is necessary to construct a large data-base matching names with biometrics. In the United States, the Federal Bureau of Investigation has such a database matching fingerprints to names, and another that matches DNA material.

Compared with passwords and access tokens, biometrics have two clear advantages. They can’t be lost or forgotten, and they can’t be readily shared, copied, or stolen. But biometric technology has been difficult to bring from the laboratory to the market. All biometric systems exhibit a certain level of false positives, in which the system erroneously declares a match when it shouldn’t, and false negatives, in which the system erroneously declares that two biometrics are from different people, when in fact they are from the same person. To reduce the possibility of false matches, some biometric systems combine the biometric with a password or token. In the case of passwords, a user is typically asked to type a secret identification code, such as a PIN, and then give a biometric sample, such as a voice print. The system uses that PIN to retrieve a specific stored profile, which is then compared with the sample from the profile. In this manner, the system only needs to compare the provided biometric with a single stored measurement, rather than with the entire database.

Biometrics are not perfect:

• A person’s biometric “print” must be on file in the computer’s database before that person can be identified.

• If the database of biometric records is compromised, then the biometric identification is worthless.

• Unless the measuring equipment is specially protected, the equipment is vulnerable to sabotage and fraud. For example, a clever thief could defeat a voice-recognition system by recording a person speaking his passphrase and then playing it back.

Location: someplace where you are

With the development of computer systems that can readily determine the location of their users, it is now possible to deploy position-based authentication systems. Although the Global Positioning System (GPS) can be readily used for obtaining location information, there are two serious hindrances for GPS in this application: the fact that GPS doesn’t usually work indoors, and the fact that there is no way to securely get the positional information from the GPS receiver to the remote service that needs to do the verification. A better choice for position-based authentication is the positional services offered by some mobile telephone networks. With these systems, the network can determine the user’s location and then directly report this information to the service, without risking that the information may be compromised while the user is authenticated.

A simple form of location-based authentication is to have a particular terminal or computer that is authorized to perform a special function. People who are in other locations are prohibited from exercising privilege. To date, location has not been used as a general system for authentication.

Using Public Keys for Identification

The identification and authentication techniques mentioned earlier all share a common flaw: to reliably identify an individual, that person must be in the presence of the person or computer that is performing the identification. If the person is not present—if the identification is being performed by telephone, by fax, or over the Internet—then there is high potential for fraud or abuse because of replay attacks.

Imagine a situation in which one computer acquires a user’s fingerprint and another performs the verification. In this case, it is possible for an attacker to intercept the code for the digitized fingerprint as it moves over the network. Once the attacker has the fingerprint transmission, the attacker can use it to impersonate the victim. Replay attacks are a fundamental attack against the digital identification systems mentioned so far.

Properly implemented, public key cryptography can eliminate the risk of replay attacks. When public key systems are used for identification, the private key is used to create a signature and the public key is used to verify that signature. As the private key never leaves the possession of the person being identified—it never gets sent over the wire—there is no opportunity for an attacker to intercept the private key and use it for malicious purposes.

Public key cryptography can be used for either offline authentication or online authentication. In the case of offline authentication, a user creates a digitally-signed message that can be verified at a point in the future. In the case of online authentication, a user authenticates in real time with a remote server. The remote server sends the user’s computer randomly-generated challenge data, and the user’s computer digitally signs the challenge with the user’s private key and returns it. Or, in another variation, the remote server encrypts a challenge with the user’s public key and sends the encrypted challenge to the user, who proves her identity by decrypting the challenge and returning it encrypted with the server’s public key. Because of the challenge-response protocol, online systems are generally more secure than offline systems.

Managing Private Keys

When a digital signature is used to “prove someone’s identity,” identity proving is not precisely what is taking place. Being able to create a valid digital signature doesn’t prove you are a particular person: it proves you have possession of a particular private key. That’s why it’s possible to find keys on public key servers purporting to be for Hillary Clinton and Batman.

For digital signature validation to become identity authentication, several preconditions need to be met:

1. Each private key/public key pair must be used by only one person.

2. The private key must be kept secure, lest it be compromised, captured, and used fraudulently by others.

3. There needs to be some sort of trust mechanism in place, so that the person verifying the identity can trust or believe that the name on the key is in fact the correct name.

If keys are carelessly generated, then it may be possible for an attacker to take a public key and determine the corresponding private key. If keys are not stored properly, then the attacker may simply be able to steal the private key.

While these rules look simple on the surface, in practice they can be exceedingly difficult to implement properly. Even worse, frequently it is difficult to evaluate a company’s public key system and decide if it is more secure or less secure than a competing system.

There are a number of different alternatives for creating and storing keys. Roughly in order of decreasing security, they are:

1. Employ a crypto-graphic coprocessor such as a smart card. A typical public key-compatible smart card has a small microprocessor with a hardware random number generator for creating keys and performing the basic public key algorithms; it also has a region of memory that can hold the keys and public key “certificates”. In theory, the private key never actually leaves the card. Instead, if you want to sign or decrypt a piece of information, that piece of information has to be transmitted into the card, and the signed or decrypted answer transmitted off the card. Thus, attackers cannot use the private key unless they have possession of the smart card. Smart cards can be augmented with PINs, passphrases, fingerprint readers, or other biometric devices, so that the card will not create a signature unless the holder is authenticated to the card.

Smart cards aren’t without their drawbacks, however. Some types are quite fragile. If the card is lost, stolen, or damaged, the keys it contains are gone and no longer available to the user. Thus, if the keys on the card are to be used for long-term encryption of information, it may be desirable to have some form of card duplication system or key escrow to prevent key loss. Such measures are not needed, however, if the keys are only used for digital signatures. If a signing key is lost, it is only necessary to create a new signing key: no information is lost. Smart cards are not completely tamper-proof. Cryptographic smart cards implement tiny operating systems: flaws in these operating systems can result in the compromise of key material. It is also possible to physically analyze a card and force it to divulge its key. Nevertheless, smart cards are currently the most secure way to store private keys.

2. Generate them on a desktop computer and then store the encrypted keys on a floppy disk or flash disk. When the key is needed, the user inserts the floppy disk into the computer’s drive; the computer reads the encrypted private key into memory, decrypts the key, and finally uses the key to sign the requested information. This technique is less secure than the smart card because it requires that the private key be transferred into the computer’s memory, where it could be attacked and compromised by a computer virus, Trojan horse, or other rogue program.

3. Generate the key inside the computer, then encrypt the key using a passphrase and store the key in a file on the computer’s hard disk. This is the technique that programs such as PGP and Netscape Navigator use to protect private keys. This technique is convenient. The disadvantage is that if somebody gains access to your computer and knows your pass-phrase, he or she can access your private key. And because the key must be decrypted by the computer to be used, it is vulnerable to attack inside the computer’s memory by a rogue program or a Trojan horse.

4. The least secure way to generate a public key/private key pair is to let somebody else do it for you, and then to download the private and public keys. The fundamental problem with this approach is that the private key is by definition compromised: somebody else has a copy of it. Nevertheless, some organizations (and some governments) require that people use third-party key generation for this very reason: so that the organization will have a copy of each user’s key, allowing the organization to decrypt all email sent to the individual.

In practice, most cryptographic systems use the third option—generating a key on a desktop computer and then storing the key on the computer’s hard disk.

Digital Certificates

The use of digital certificates and a public key infrastructure (PKI) are attempts to tie absolute identity to digital signatures. A digital certificate is a special kind of digital signature—it is a digital signature that comes with an identity, which is designed to be interpreted by computers in an automated way. A public key infrastructure is a collection of technologies and policies for creating and using digital certificates. The effectiveness of these systems comes from a marriage of public key cryptography, carefully written and maintained policies, and the legal system.

The problem of digital identification with public keys has profoundly deep philosophical implications. How can you ever know if a public key really belongs to the individual or an organization whose name is on the key? How can we ever really know anything? As it turns out, we can know quite a bit about the identity of key holders and the authenticity of digital certificates, as long as certain rules and procedures are followed in the creation and protection of these instruments.

There are three basic approaches to insuring that a public key really belongs to the individual it claims to:

1. Get the public key directly from the individual and confirm the key’s integrity in a manner that cannot be falsified.

2. Determine that another individual that you trust vouches for the key.

3. Determine that a reliable central authority has certified the key.

Confirming a Key’s Integrity Personally

One way to be sure that you’ve got Jane Trocard’s public key is to meet with Jane and have her read out her copy of the key and compare it, number-for-number, with yours. If you know Jane well enough, and if you trust the telephone system, you might do this comparison over the telephone instead – but not over the Internet, where someone could intercept the comparison and replace the numbers with those of a bogus key.

Because public keys are based on very long numbers, number-by-number comparison is inconvenient. Instead, you and Jane might independently compute a shorter cryptographic message digest and compare the characters in that digest. Such digests are often call “key fingerprints”. Some avid public key cryptography users print their key fingerprints on their business cards; if you’ve received a business card directly from Jane, you can later download her public key and verify its integrity.

Certifying Other People’s Keys

Once you know that Jane’s key is valid – that it’s really her key – you might be willing to accept other public keys if Jane will vouch for them. Jane can vouch for other people’s keys by signing them with her own key. When you receive a key signed by Jane’s key, you know that Jane herself has signed it, because you know that Jane’s key is valid and you assume only Jane has access to it.

The decision to accept keys that Jane vouches for is not based on the validity of Jane’s key, but on the level of trust you have for Jane herself to be careful about whose keys she vouches for. In most public key systems, these two concepts – the validity of a key and the trust you assign its owner – are independent. In some systems, you can require that two or more trusted parties each vouch for a key before you are willing to accept it as valid.

PGP users often hold “signing parties” at which they meet, in person, to verify one another’s keys and then sign them. At the end of such a party, a participant’s public key may have a dozen or more signatures that someone else can later use to decide if the key is valid. PGP users distribute their keys worldwide on PGP key servers; when you download a key from a key server, you can use the signatures to decide whether you believe that this key really identifies the user it claims to.

Certification Authorities: Third-Party Registrars

While key signing parties are a great way to meet people, experience has shown that they are not a practical way to create a national database of cross-certified public keys—the coverage is simply too uneven. Some people don’t have the time to go to key signing parties. Moreover, having somebody’s signature on your key reveals that you know each other, or at least that you met each other. That’s why most large-scale uses of public key cryptography rely on a tree of certifications, with a certification authority at the root.

A certification authority (CA) is any individual or organization that issues digital certificates.

A CA can impose standards before it signs a key; for example, a university might verify that the key that it was about to sign really belonged to a bona fide student. Another CA might not have any standards at all. The world’s largest CA, VeriSign, issues several different kinds of certificates. VeriSign signs certificates under its VeriSign Trust Network (VTN) for public use; the company also issues certificates for use within corporations. The lowest level of certificates issued by VTN have no assurance; the highest levels come with the promise that VTN attempted to establish the identity of the key holder before the certificate was issued.

Conceptually, a certificate signed by a CA looks like a cryptographically signed index card. The certificate contains the identity information of the user, signed by the certification authority’s own private key, and also lists the name of the CA, that CA’s public key, and a serial number.

To date, most certificates are a promise by the CA that a particular public key belongs to a particular individual or organization. But certificates can also be used for assertions, as in the university example. There are many different ways that a certification authority can offer service:

Internal CA

An organization can operate a CA to certify its own employees. Certificates issued by an internal CA might certify an individual’s name, position, and level of authority. These certificates could be used within the organization to control access to internal resources or the flow of information. Such an internal CA would be the basis of the organization’s public key infrastructure.

Companies can also operate internal CAs that issue certificates to customers. For example, some brokerages have required that their customers obtain certificates before they are allowed to execute high value trades over the Internet.

Outsourced CA

An organization might want to partake in the benefits of using digital certificates, but not have the technical ability to run its own certification authority. Such an organization could contract with an outside firm to provide certification services for its own employees or customers, exactly as a company might contract with a photo lab to create identification cards.

Trusted third-party CA

A company or a government can operate a CA that binds public keys with the legal names of individuals and businesses. Such a CA can be used to allow individuals with no prior relationship to establish each other’s identity and engage in legal transactions. Certificates issued by such a CA would be analogous to drivers’ licenses and identity cards issued by a state.

Before you can use the certificates issued by a CA, you need to have a copy of the CA’s public key. Public keys are distributed on certificates of their own. Currently, most of these certificates are prebundled in web browsers and operating systems. CA public keys can also be added manually by the end user.

Clearly, CAs that do not have their keys prebundled are at a disadvantage. Although Microsoft and Netscape have now opened up their browsers to any CA that can meet certain auditing requirements, the original web browsers were distributed with a small number of carefully selected CA keys. The bundling of these keys was a tremendous advantage to these CAs and a barrier to others.

Certification Practices Statement (CPS)

The certification practices statement (CPS) is a legal document CAs publish that describes their policies and procedures for issuing and revoking digital certificates. It answers the question, “What does it mean when this organization signs a key?”

CPS documents are designed to be read by humans, not by machines. A business might be willing to accept certification from a CA that guarantees minimum certification policies and a willingness to assume a certain amount of liability in the event that its certification policies are not followed—and provided that the CA is bonded by an appropriate bonding agency.

The X.509 v3 Certificate

Although certification authorities can issue any kind of certificate, in practice the vast majority of CAs issue certificates that follow the X.509 v3 standard. Likewise, most cryptographic programs and protocols, including SSL, are only designed to use X.509 v3 certificates. The only notable exception to this is PGP, which uses its own certificate format, although recent versions support reading some X.509 certificates. (The Secure Shell (ssh) program does not use certificates, but instead relies on users confirming public keys personally.)

Each X.509 certificate contains a version number, a serial number, identity information, algorithm-related information, and the signature of the issuing authority. The industry adopted X.509 v3 certificates, rather than the original X.509 certificates, because the X.509 v3 standard allows arbitrary name/value pairs to be included in the standard certificate. These pairs can be used for many purposes and allow the uses of certificates to be expanded without changing the underlying protocol.

Types of Certificates

There are four primary types of digital certificates in use on the Internet today:

Certification authority certificates

These certificates contain the public keys of CAs and either the name of the CA or the name of the particular service being certified. These certificates are typically self-signed—that is, signed with the CA’s own private key. CAs can also cross-certify, or sign each other’s master keys. What such cross-certification actually means is an open question. Microsoft Windows, Microsoft Internet Explorer, Netscape Navigator, and OpenSSL are all shipped with more than a dozen different CA certificates.

Several companies have more than one CA certificate in the CA lists that are distributed with web browsers. VeriSign has the most: over 20 different certificates. Signatures by different private keys denote different levels of trust and authentication.

Server certificates

These certificates contain the public key of an SSL server, the name of the organization that runs the server, and the DNS name of the server. Every cryptographically-enabled information server on the Internet must be equipped with a server certificate for the SSL encryption protocol to function properly. Although the originally stated purpose of these certificates was to allow consumers to determine the identity of web servers and to prevent man-in- themiddle attacks, in practice server certificates are more widely used for encryption than for server authentication.

Personal certificates

These certificates contain an individual’s name and the individual’s public key. They can have other information as well, such as the individual’s e-mail address, postal address, or birth date. They are issued by organizations to their customers or employees. Personal certificates are a substantially more secure way of having people identify themselves on the Internet than usernames and passwords. They are also required for users of the S/MIME e-mail encryption protocol.

Software publisher certificates

These certificates are used to verify the signatures on software that is distributed, such as ActiveX components and downloadable executables. Every copy of recent Windows operating systems is distributed with a number of software publisher certificates that can be used to validate the signatures on Windows applications.

Minimal disclosure certificates

Digital certificates represent a threat to the privacy of their users. When you present a certificate to a server, the server can easily record all of the information about your identity that’s present on the certificate, whether or not it’s necessary to authenticate you to that server. In many jurisdictions, an organization that obtained this information in the course of business would be free to do whatever it wished with the data.

A way to minimize the privacy threat is by using minimal disclosure certificates. These certificates allow the holder to selectively reveal specific facts that are on a certificate without revealing others. A woman who wanted to gain access to a web site for a cancer survivors group might use minimal disclosure certificates to prove to the web site that she was a woman over 21 who had breast cancer without revealing her name or address. Minimal disclosure certificates were invented by the mathematician Stefan Brands and exclusively licensed in February 2000 to the Canadian corporation Zero Knowledge Systems.212

Revocation

Besides issuing certificates, CAs need a way of revoking them if the private key is compromised or the CA makes a mistake. Certificates may also need to be revoked when an employee is terminated.

The need for effective revocation mechanisms was made particularly clear in March 2001, when Microsoft announced that VeriSign had issued two certificates in January “to an individual who fraudulently claimed to be a Microsoft employee. The common name assigned to both certificates is Microsoft Corporation.” Microsoft went on to note that “the ability to sign executable content using keys that purport to belong to Microsoft would clearly be advantageous to an attacker who wished to convince users to allow the content to run.”213

212 http://www.wired.com/news/technology/0,1282,34496,00.html

213 http://www.microsoft.com/technet/security/bulletin/MS01-017.asp

Certificate revocation lists

One approach to revocation is the certificate revocation list (CRL). A CRL is a list of every certificate that has been revoked by the CA that has not yet expired for other reasons. Ideally, a CA issues a CRL at regular intervals. Besides listing certificates that have been revoked, the CRL states how long it will be valid and where to get the next CRL.

Current practice is that X.509 v3 certificates should contain a field called the CRL distribution point (CDP). In theory, a program that wishes to verify if a certificate has been revoked should be able to download a CRL from the CDP to determine if the certificate has been revoked. As most certificates will be issued by a small number of CAs, it is reasonable to assume that a program might download a new CRL every day or every hour, and then cache this list for successive lookups. An organization with limited Internet connectivity could download the CRL once and distribute it to its users.

In practice, CRLs and CDPs have had a variety of problems:

• If a CA is very popular, it is likely that the CRLs will grow very large. VeriSign’s 900K CRL for its SSL server certificates can take more than 20 minutes to download over a dialup connection.

• There is a period between the time that a certificate is revoked and the time that the new CRL is distributed when a certificate appears to be valid but is not.

• The information contained in CRLs can be used for traffic analysis.

• Many programs do not properly implement CRLs and CDPs.

In the case of the fraudulently-issued Microsoft certificate, the bogus certificate was revoked and listed in VeriSign’s CRL. Unfortunately, the certificates that VeriSign issued did not contain valid CDPs. (According to VeriSign, CDPs are not present in Authenticode certificates because of a bug in the implementation of Authenticode distributed with Internet Explorer 3.02.) Without the CDP, a program that attempted to verify the authenticity of the fraudulentlyissued certificates would not know where to find the CRL on which the certificates were listed.214

214 In the end, Microsoft had to issue an operating system patch to resolve the problem. The patch contained an additional revocation handler that causes Internet Explorer to consult a local CRL to evaluate the authenticity of certificates, and a local CRL listing the two mistakenly issued VeriSign certificates.

Real-time certificate validation

An alternative to CRLs is to use real-time validation of certificates. These systems consult an online database operated by the certification authority every time the authenticity of a certificate needs to be validated. Real-time certification validation systems neatly dispense with the CRL problem, although they do require a network that is reliable and available.

The primary problem with real-time validation is one of scale. As there are more and more users of certificates, the validation servers need to be faster and faster to serve the larger user community. Furthermore real-time systems are vulnerable to denial of service (DoS) attacks. If it is not possible for a business to connect to the revocation server, what should be done with a certificate—trust it or discard it? If the default is to trust it, fraud can be committed by flooding the revocation server so as to make it unresponsive while a revoked certificate is used. If the default is to reject requests when the revocation server is unreachable, then it is possible to cause all transactions to be rejected using a DoS attack, thus damaging the reputation of the business through a cascading denial of service.

Public Key Infrastructure

Public key infrastructure (PKI) is the system of digital certificates, certification authorities, tools, systems, and hardware that are used to deploy public key technology.

Many of the early proponents of PKI envisioned a single PKI, operated by or for governments, which would provide state-certified certificates. The public PKI was a grand vision, but so far it hasn’t happened. Companies such as VeriSign have issued millions of certificates to verify the identity of individuals and organizations, and the keys to sign these certificates have been widely distributed. Some of these so-called trust hierarchies, such as the trust hierarchy used to certify web server certificates, are used by more than a hundred million people. But they are run by private businesses, and not by governments. The word “public” in PKI refers to public keys, rather than to the public at large.

Shortcomings of Today’s CAs

It’s unfortunate, but if you look closely into the root certificates that are bundled with Internet Explorer and Netscape Navigator, you’ll see that there are significant inconsistencies and quality control problems with today’s CAs.

Lack of permanence for Certificate Policies field

Internet Explorer’s Certificate panel allows you to automatically open the web page that is associated with the certification practices statement for each of the certificates that is registered. This field is indicated as a URL in a field called “Certificate Policies” in the X.509 v3 certificate.

It is very important for a CA to maintain a web page at every URL that is listed in every certificate that it has ever issued. If these URLs move, links should be left in their place. If a CA changes its CPS, then it must archive each CPS at a unique URL. These links must remain accessible for the lifetime of any signed certificate that references the CPS. This is because the legal meaning of the certificate cannot be determined without reading the certificate practices statement. Furthermore, because it is possible that the meaning of a signature might be questioned many years after the signature is created, the URLs should probably remain active for a period of at least 20 years.

Unfortunately, many CA certificates point to CPSs that are no longer accessible. The self-signed certificate distributed with Internet Explorer 5.0 for the Autoridad Certificadora del Colegio Nacional de Correduria Publica Mexicana, A.C. is valid from June 29, 1999 until June 29, 2009. The certificate claims that the certificate practices statement for this key is located at http://www.correduriapublica.org.mx/RCD/dpc. Nevertheless, by April 2001 the URL for that CPS was not accessible.

Inconsistencies in certificate fields

The CA certificates that are bundled into Netscape Navigator and Internet Explorer are supposed to be the basis for the world’s e-commerce infrastructure and legally binding agreements. Complicating this goal is the fact that there is a huge variation in the ways that the certificate fields are being used by different organizations. In particular, the “Subject” field, which identifies the issuer by its Distinguished Name, has no standard format, and different CA certificates include wildly different qualifiers in their Subject.

Consistency in the use of the Distinguished Name and other fields is vital if certificates are to be processed in a programmatic way with software. Without this consistency, certificates need to be visually inspected by individuals who are trained to understand all of the different styles and formats that legitimate names can have, so that valid certificates can be distinguished from rogue ones.

Unrealistic expiration dates

Early versions of the Netscape Navigator web browser were distributed with CA certificates that had expiration dates between December 25, 1999 and December 31, 1999. These products were in use far longer than anybody anticipated. When the end of 1999 rolled around, many of the products with these old CA certificates inside them simply stopped working. Although it should have been possible to simply download new certificates, users were advised to upgrade their entire applications because of other security problems with these early products. Many users were not happy that the software they had been depending on suddenly stopped working.

As a result of this experience, many CAs have decided to err in the other direction. They have started distributing CA certificates with unrealistically long expiration times. All of the certificates distributed with Internet Explorer

5.0 are 1024-bit RSA certificates, yet more than half of these certificates have expiration dates after January 1,

2019! VeriSign distributes eight certificates with Internet Explorer 5.5 that have expiration dates in the year 2028! Many cryptographers believe that 1024-bit RSA will not be a secure encryption system at that point in the future.

PKI Policy Issues

The need for a widespread PKI is compelling. There are growing incidents of fraud on the Internet, and there is an increasing need to use digital signatures to do business. Yet widespread PKI seems further away today than it was in the mid 1990’s. It’s an article of faith among computer security specialists that private keys and digital certificates can be used to establish identity. But these same specialists will pick up the phone and call one another when the digital signature signed at the bottom of an e-mail message doesn’t verify. That’s because it is very, very easy for the technology to screw up.

Here are a few of the problems that must be faced in building a true PKI.

Private Keys Are Not People

Digital signatures facilitate proofs of identity, but they are not proofs of identity by themselves. Unless the private key is randomly generated and stored in such a way that it can only be used by one individual, the entire process may be suspect.

Unfortunately, both key generation and storage depend on the security of the end user’s computer. But the majority of the computers used to run Netscape Navigator or Internet Explorer are unsecure. Many of these computers run software that is downloaded from the Internet without knowledge of its source. Some of these computers are infected by viruses. Some of the programs downloaded have Trojan horses pre-installed. And the most common operating system and browser are terribly buggy, with hundreds of security patches issued over the past few years, so it is possible that any arbitrary system in use on the network has been compromised in the recent past by parties unknown.

The widespread use of smart cards and smart card readers may make it much more difficult to steal somebody’s private key. But it won’t be impossible to do so.

Distinguished Names Are Not People

Protecting private keys is not enough to establish the trustworthiness of the public key infrastructure. How do you determine if the name in the Distinguished Name field is really correct? Each CA promises that it will follow its own certification rules when it signs its digital signature. How do you know that a CA’s rules will assure that a distinguished name on the certificate really belongs to the person they think it does?

How do you evaluate the trustworthiness of a CA? Should private companies be CAs, or should that task be reserved for nations? Would a CA ever break its rules and issue fraudulent digital identification documents? After all, governments, including the United States, have been known to issue fraudulent passports when their interests have demanded that they do so.

How do you compare one CA with another CA? Some CAs obtain third-party audits including SAS 70215 (service auditor report) or Web Trust for CAs216 (attestation report); others do not. The American Bar Association Information Security Committee has published a book, PKI Assessment Guidelines, but few users have the skill or

the access to be able to assess the CAs that they might employ.

In theory, many of these questions can be resolved through the creation of standards, audits, and formal systems of accreditation. Legislation can also be used to create standards. But in practice, efforts to date are not encouraging.

There Are Too Many Robert Smiths

What do you do with a certificate that says “Robert Smith” on it? How do you tell which Robert Smith it belongs to? Clearly, a certificate must contain more information than simply a person’s name: it must contain enough information to uniquely and legally identify an individual. Unfortunately, you (somebody trying to use Robert Smith’s certificate) might not know this additional information—so there are still too many Robert Smiths for you. Of course, if these digital certificates did have fields for a person’s age, gender, or photograph, users on the Internet would say that these IDs violated their privacy if they disclosed that information without the user’s consent. And they would be right. That’s the whole point of an identification card: to remove privacy and anonymity, producing identity and accountability as a result.

Digital Certificates Allow for Easy Data Aggregation

Over the past two decades, universal identifiers such as the U.S. Social Security number have become tools for systematically violating people’s privacy. Universal identifiers can be used to aggregate information from many different sources to create comprehensive data profiles of individuals.

Digital certificates issued from a central location have the potential to become a far better tool for aggregating information than the Social Security number ever was. That’s because digital signatures overcome the biggest problem with Social Security numbers: poor data. People sometimes lie about their Social Security numbers; other times, these numbers are mistyped.

Today, when two businesses attempt to match individually identified records, the process is often difficult because the numbers don’t match. By design, digital certificates will simplify this process by providing for verified electronic entry of the numbers. As a result, the practice of building large data banks of personal information aggregated from multiple sources is likely to increase.

How Do You Loan a Key?

Suppose Carl is sick in the hospital and he wants you to go into his office and bring back his mail. To do this, he needs to give you his private key. Should he be able to do that? Should he revoke his key after you bring it back? Suppose he’s having a problem with a piece of software. It crashes when he uses private key A, but not when he uses private key B. Should he be legally allowed to give a copy of private key A to the software developer so she can figure out what’s wrong with the program? Or is he jeopardizing the integrity of the entire public key infrastructure by doing this?

215 Statement on Auditing Standards (SAS) No. 70, Service Organizations, is an internationally recognized auditing standard developed by the American Institute of Certified Public Accountants (AICPA). A SAS 70 examination signifies that a service organization has had its control objectives and control activities examined by an independent accounting and auditing firm.

216 Under the WebTrust Program for CAs, an independent and qualified auditor uses an established, recognized, and accepted set of principles and criteria to assess whether an active certification authority meets a minimum standard for disclosures, policies, practices, and monitoring procedures.

Suppose a private key isn’t associated with a person, but is instead associated with a role that person plays within a company. For example, consider a private key that’s used for signing purchase orders. Is it okay for two people to have that private key? Or should the company create two private keys, one for each person who needs to sign purchase orders?

Network-based Authentication

Several solutions to the problem of user authentication have been proposed for environments in which there are multiple workstations available to users, connected to one another through an untrusted and potentially unsecure network. For convenience, we’d like to have user account data stored on a central server, but for redundancy we might like to have that central server’s data replicated on other servers in real time. For security, we need to ensure that when a user logs into a workstation, his identity is authenticated against the central server’s data store without exposing private data on the untrusted network. Although solutions to this problem have been offered — including NIS, NIS+, Kerberos, and LDAP – none has been universally adopted. NIS and NIS+ are primarily used in environments with many Unix workstations; Kerberos and LDAP are increasingly seen in these environments as well, and are also part of Microsoft Windows NT-based operating systems.

Sun’s Network Information Service (NIS)

One of the oldest and best-known distributed administrative database systems is Sun’s Network Information Service (NIS). It was superseded years ago by NIS+, an enhanced but more complex successor to NIS, also by Sun. More recently, LDAP (Lightweight Directory Access Protocol) servers are becoming more popular, and Sun users are migrating to LDAP-based services. However, even though NIS has been deprecated by Sun, it is still widely used in many environments.

NIS is a distributed database system that lets many computers share password files, group files, host tables, and other files over the network. Although the files appear to be available on every computer, they are actually stored on only a single computer, called the NIS master server (and possibly replicated on a backup, or slave server). The other computers on the network, NIS clients, can use the databases (such the password file) stored on the master server as if they were stored locally. These databases are called NIS maps.

With NIS, a large network can be managed more easily because all of the account and configuration information can be stored and maintained on a single machine, yet used on all the systems in the network.

Some files are replaced by their NIS maps. Other files are augmented. For these files, NIS uses the plus sign (+) to tell the system that it should stop reading the file (e.g., /etc/passwd) and should start querying the appropriate map (e.g., passwd) from the NIS server. The server maintains multiple maps, normally corresponding to files stored in the /etc directory, such as /etc/passwd, /etc/hosts, and /etc/services.

For example, the /etc/passwd file on a client might look like this:

root:si4N0jF9Q8JqE:0:1:Mr. Root:/:/bin/sh

+::999:999:::

This causes the program reading /etc/passwd on the client to make a network request to read the passwd map on the server. Normally, the passwd map is built from the server’s /etc/passwd file, although this need not necessarily be the case.

When NIS is scanning the /etc/passwd file, it will stop when it finds the first line that matches. You can restrict the importing of accounts to particular users by following the “+” symbol with a particular username. You can also exclude certain usernames from being imported by inserting a line that begins with a minus sign (-).

NIS also allows you to selectively import some fields from the /etc/passwd database but not others. For example, if you have the following entry in your /etc/passwd file:

root:si4N0jF9Q8JqE:0:1:Mr. Root:/:/bin/sh

+:*:999:999:::

Then all of the entries in the NIS passwd map will be imported, but each will have its password entry changed to *, effectively preventing it from being used on the client machine. You get all the UIDs and account names, so that file listings show the owner of files and directories as usernames. The entry also allows the ~user notation in the various shells to correctly map to the user’s home directory (assuming that it is mounted using NFS).

NIS Domains

When you configure an NIS server, you must specify an NIS domain. These domains are not the same as DNS domains. While DNS domains specify a region of the Internet, NIS domains specify an administrative group of machines.

The Unix domainname command is used to display and to change your domainname. A computer can only be in one NIS domain at a time, but it can serve any number of NIS domains.

Don’t use your Internet domain as your netgroup domain. Setting the two domains to the same name has caused problems with some versions of sendmail. It is also a security problem to use an NIS domain that can be easily guessed. Hacker toolkits that attempt to exploit NIS or NFS bugs almost always try variations of the Internet domain name as the NIS domainname before trying anything else. (Of course, the domainname can still be determined in other ways.)

NIS Netgroups

NIS netgroups allow you to create groups for users or machines on your network. Netgroups are similar in principle to local groups for users, but they are much more complicated.

The primary purpose of netgroups is to simplify your configuration files, and to give you less opportunity to make a mistake. By properly specifying and using netgroups, you can increase the security of your system by limiting the individuals and the machines that have access to critical resources.

The netgroup database is kept on the NIS master server in the file /etc/netgroup or /usr/ etc/netgroup. This file consists of one or more lines that have the form:

groupname member1 member2 ...

Each member can specify a host, a user, and a NIS domain. The members have the form:

(hostname, username, domainname)

If a username is not included, then every user at the host hostname is a member of the group. If a domainname is not provided, then the current domain is assumed.217

217 It is best to create netgroups in which every member has a username (a netgroup of users) or in which every member has a hostname but does not have a username (a netgroup of hosts). Creating netgroups in which some members are users and some members are hosts makes mistakes somewhat more likely.

Setting up netgroups

The /etc/yp/makedbm program (sometimes found in /usr/etc/yp/makedbm) processes the netgroup file into a number of database files that are stored in:

/etc/yp/domainname/netgroup.dir

/etc/yp/domainname/netgroup.pag

/etc/yp/domainname/netgroup.byuser.dir

/etc/yp/domainname/netgroup.byuser.pag

/etc/yp/domainname/netgroup.byhost.dir

/etc/yp/domainname/netgroup.byhost.pag

Note that /etc/yp may be symbolically linked to /var/yp on some machines.

If you have a small organization, you might simply create two netgroups: one for all of your users, and a second for all of your client machines. These groups will simplify the creation and administration of your system’s configuration files.

If you have a larger organization, you might create several groups. For example, you might create a group for each department’s users. You could then have a master group that consists of all of the subgroups. Of course, you could do the same for your computers as well.

Consider the following science department:

Math (mathserve,,) (math1,,) (math2,,) (math3,,)

Chemistry (chemserve1,,) (chemserve2,,) (chem1,,) (chem2,,) (chem3,,)

Biology (bioserve1,,) (bio1,,) (bio2,,) (bio3,,)

Science Math Chemistry Biology

Netgroups are important for security because you use them to limit which users or machines on the network can access information stored on your computer. You can use netgroups in NFS files to limit who has access to the partitions, and in data files such as /etc/passwd, to limit which entries are imported into a system.

Using netgroups to limit the importing of accounts

You can use the netgroups facility to control which accounts are imported by the /etc/ passwd file. For example, if you want to simply import accounts for a specific net-group, then follow the plus sign (+) with an at sign (@) and a netgroup:

root:si4N0jF9Q8JqE:0:1:Mr. Root:/:/bin/sh

+@operators::999:999:::

The above will bring in the NIS password map entry for the users listed in the operators group. You can also exclude users or groups using a minus sign (-) if you list the exclusions before you list the net-groups.

The +@netgroup and -@netgroup notation does not work on all versions of NIS, and historically has not worked reliably on others. If you intend to use these features, check your system to verify that they are behaving as expected. Simply reading your documentation is not sufficient.

Limitations of NIS

NIS has been the starting point for many successful penetrations into Unix networks. Because NIS controls user accounts, if you can convince an NIS server to broadcast that you have an account, you can use that fictitious account to break into a client on the network. NIS can also make confidential information, such as encrypted password entries, widely available.

There are design flaws in the code of the NIS implementations of several vendors that allow a user to reconfigure and spoof the NIS system. This spoofing can be done in two ways: by spoofing the underlying remote procedure call (RPC) system, and by spoofing NIS.

Spoofing RPC

Remote procedure calls (RPC) enable one system on a network to call functions on another system. The NIS system depends on the functioning of the RPC portmapper service. This is a daemon that matches supplied service names for RPC with IP port numbers at which those services can be contacted. Servers using RPC will register themselves with portmapper when they start, and will remove themselves from the portmap database when they exit or reconfigure.

Early versions of portmapper allowed any program to register itself as an RPC server, allowing attackers to register their own NIS servers and respond to requests with their own password files. Most current versions of portmapper rejects requests to register or delete services if they come from a remote machine, or if they refer to a privileged port and come from a connection initiated from a unprivileged port. Thus only the superuser can make requests that add or delete service mappings to privileged ports, and all requests can only be made locally. However, not every vendor’s version of the portmapper daemon performs these checks.

Note that NFS and some NIS services often register on unprivileged ports. In theory, even with the checks outlined above, an attacker could replace one of these services with a specially written program that would respond to system requests in a way that would compromise system security.

Spoofing NIS

NIS clients get information from an NIS server through RPC calls. A local daemon, ypbind, caches contact information for the appropriate NIS server daemon, ypserv. The ypserv daemon may be local or remote.

Under early SunOS versions of the NIS service (and possibly versions by some other vendors), it was possible to instantiate a program that acted like ypserv and responded to ypbind requests. The local ypbind daemon could then be instructed to use that program instead of the real ypserv daemon. As a result, an attacker could supply his or her own version of the password file (for instance) to a login request! (The security implications of this should be obvious.)

Current NIS implementations of ypbind have a –secure or –s command line flag that can be provided when the daemon is started. If the flag is used, the ypbind daemon will not accept any information from a ypserv server that is not running on a privileged port. Thus, a user-supplied attempt to masquerade as the ypserv daemon will be ignored. A user can’t spoof ypserv unless that user already has superuser privileges. There is no good reason not to use the -secure flag.

Unfortunately, the -secure flag has a flaw. If the attacker is able to subvert the root account on any other machine on the local network and start a version of ypserv using his own NIS information, he need only point the target ypbind daemon to that server. The compromised server would be running on a privileged port, so its responses would not be rejected. An attacker could also write a “fake” ypserv that runs on a PC-based system. Privileged ports have no meaning in this context, so any user can run the server on any port and feed information to the target ypbind process.

NIS is confused about “+”

Even when NIS clients contact the correct servers, NIS can present other security difficulties. For example, a combination of installation mistakes and changes in NIS itself has caused some confusion with respect to the NIS plus sign (+) in the /etc/passwd file.

If you use NIS, be very careful that the plus sign is in the /etc/passwd file of your clients, and not your servers. On a NIS server, the plus sign can be interpreted as a user-name under some versions of the Unix operating system. The simplest way to avoid this problem is to make sure that you do not have the “+” account on your NIS server.

Attempting to figure out what to put on your client machine is another matter. With early versions of NIS, the following line was distributed:

+::0:0::: Correct on SunOS and Solaris

Unfortunately, this line presented a problem. When NIS was not running, the plus sign was sometimes taken as an account name, and anybody could log into the computer by typing + at the login: prompt—and without a password! Even worse, the person logged in with superuser privileges.218

218 On Sun’s NIS implementation, and possibly others, this danger can be ameliorated somewhat by avoiding 0 or other local user values as the UID and GID values in NIS entries in the passwd file.

One way to minimize the danger was by including a password field for the plus user. Specify the plus sign line in the form:

+:*:0:0::: On NIS clients only

Unfortunately, under some versions of NIS this entry actually means “import the passwd map, but change all of the encrypted passwords to “*”, which effectively prevents everybody from logging in. This entry wasn’t right either!

The easiest way to deal with this confusion is simply to attempt to log into your NIS clients and servers using a + as a username. You may also wish to try logging in with the network cable unplugged, to simulate what happens to your computer when the NIS server cannot be reached. In either case, you should not be able to log in by simply typing + as a username. This test will tell you if your server is properly configured.

If you are running a recent version of your operating system, do not think that your system is immune to the + confusion in the NIS sub-system. In particular, some NIS versions on Linux got this wrong too.

Improving NIS security

NIS databases contain sensitive information. There are several ways to prevent unauthorized disclosure of your NIS databases. As with most security improvements, you can combine several of these for a layered “defense-in-depth” approach:

1. Protect your site with a firewall, or at least a smart router, and do not allow the UDP packets associated with RPC to cross between your internal network and the outside world. Unfortunately, because RPC is based on the portmapper, the actual UDP port that is used is not fixed. In practice, the only safe strategy is to block all UDP packets except those that you specifically wish to let cross.

2. Use a portmapper program that allows you to specify a list of computers (by hostname or IP address) that should be allowed or denied access to specific RPC servers. If you don’t have a firewall, an attacker can still scan for each individual RPC service without consulting the portmapper, but if they do make an attempt at the portmapper first, an improved version may give you warning.

3. Find out if your version of NIS uses the /var/yp/securenets file on NIS servers. This file, when present, can be used to specify a list of networks that may receive NIS information. Other versions may provide other ways for the ypserv daemon to filter addresses that are allowed to access particular RPC servers.

4. Don’t tighten up NIS but forget about DNS! If you decide that outsiders should not be able to learn your site’s IP addresses, be sure to run two nameservers — one for internal use and one for external use.

Sun’s NIS+

NIS was designed for a small, friendly computing environment. As Sun Microsystem’s customers began to build networks with thousands of workstations, NIS proved to be too unwieldy and insecure for enterprise use. Sun Microsystems started working on an NIS replacement in 1990. That system was released a few years later as NIS+.

NIS+ quickly earned a bad reputation. By all accounts, the early releases were virtually untested and rarely operated as promised. Furthermore, the documentation was confusing and incomplete. Eventually, Sun worked the bugs out of NIS+ and today it is a more reliable system for secure network management and control. An excellent reference for people using NIS+ is Rick Ramsey’s book, All About Administrating NIS+ (SunSoft Press, Prentice Hall, 1994).

What NIS+ Does

NIS+ creates network databases that are used to store information about computers and users within an organization. NIS+ calls these databases tables; they are functionally similar to NIS maps. Unlike NIS, NIS+ allows for incremental updates of the information stored on replicated database servers throughout the network.

Each NIS+ domain has exactly one NIS+ root domain server. This is a computer that contains the master copy of the information stored in the NIS+ root domain. The information stored on this server can be replicated, allowing the network to remain usable even when the root server is down or unavailable. There may also be NIS+ servers for subdomains.

Entities that communicate using NIS+ are called NIS+ principals. An NIS+ principal may be a host or an authorized user. Each NIS+ principal has a public key and a secret key, which are stored on an NIS+ server in the domain.

All communication between NIS+ servers and NIS+ principals take place through Secure RPC, a version of RPC that authenticates and protects procedure calls with DES encryption. This makes the communication resistant to both eavesdropping and spoofing attacks. NIS+ also oversees the creation and management of Secure RPC keys. By virtue of using NIS+, every member of the organization is enabled to use Secure RPC.

NIS+ Tables and Other Objects

All information stored on an NIS+ server is stored in the form of objects. NIS+ supports three fundamental types of objects. Tables store configuration information; groups collectively refer to a set of NIS+ principals and are used for authorization; directories are containers for tables, groups, or other directories, and provide a tree structure to the NIS+ server.

NIS+ predefines 16 tables, including tables for hosts and networks, protocols and services, user accounts and passwords, user groups and netgroups, e-mail aliases, and others; users are free to create additional tables of their own.

Using NIS+

Using an NIS+ domain can be remarkably pleasant. When a user logs in to a workstation, the login process automatically acquires the user’s NIS+ security credentials and attempts to decrypt them with the user’s login password.

If the account password and the NIS+ credentials password are the same (and they usually are), the NIS+ keyserv process will cache the user’s secret key and the user will have transparent access to all Secure RPC services. If the account password and the NIS+ credentials password are not the same, then the user will need to manually log in to the NIS+ domain by using the keylogin command. NIS+ users change their passwords with the NIS+ nispasswd command, which works in much the same way as the standard UNIX passwd command.

NIS+ security is implemented by providing a means for authenticating users, and by establishing access control lists that control the ways that those authenticated users can interact with the information stored in NIS+ tables. NIS+ provides for two authentication types. Local authentication is based on the UID executing an NIS+ command and is used largely for administrating the root NIS+ server. DES authentication is based on Secure RPC.

Each NIS+ object has an owner, which is usually the object’s creator. (An object’s owner can be changed with the nischown command.) NIS+ objects also have access control lists, which are used to control which principals have what kind of access to the object: read, modify, create, destroy, or a combination. Four types of principals may have access rights to an object: nobody (unauthenticated requests), the object’s owner, principals in the object’s group, and other authenticated principals.

NIS+ tables may provide additional access privileges for individual rows, columns or entries that they contain. Thus, all authenticated users may have read access to an entire table, but each user may further have the ability to modify the row of the table associated with the user’s own account. Note that while permissions on individual rows, columns, or entries can broaden the access control list, they cannot impose more restrictive rules.

Limitations of NIS+

If properly configured, NIS+ can be a very secure system for network management and authentication. However, like all security systems, it is possible to make a mistake in the configuration or management of NIS+ that would render a network that it protects somewhat less than secure. Here are some things to be aware of:

Do not run NIS+ in NIS compatibility mode

NIS+ has an NIS compatibility mode that allows the NIS+ server to interoperate with NIS clients. If you run NIS+ in this mode, then any NIS server on your network (and possibly other networks as well) will have the ability to access any piece of information stored within your NIS+ server.

Manually inspect the permissions of NIS+ objects on a regular basis

System integrity checking software does not exist (yet) for NIS+. In its absence, you must manually inspect the NIS+ tables, directories, and groups on a regular basis. Be on the lookout for objects that can be modified by Nobody or by World; also be on the lookout for tables in which new objects can be created by these principal classes.

Secure the computers on which your NIS+ servers are running

Your NIS+ server is only as secure as the computer on which it is running. If attackers can obtain root access on your NIS+ server, they can make any change that they wish to your NIS+ domain, including creating new users, changing user passwords, and even changing your NIS+ server’s master password.

Use NIS+ security level 2 on servers

NIS+ servers can operate at three security levels, denoted 0, 1, and 2. Only at level 2 is full security authentication and access checking enabled, and only level 2 security should be used for NIS+ servers.

Kerberos

At the Massachusetts Institute of Technology in the late 1980’s, hundreds of high-performance workstations with big screens, fast (for the time) processors, small disks, and Ethernet interfaces replaced the older system of a few large timesharing computers with terminals. The goal was to allow any user to sit down at any computer and enjoy full access to his files and to the network.

As soon as the workstations were deployed, the problem of network eavesdropping became painfully obvious; with the network accessible from all over campus, nothing prevented students (or outside intruders) from running network spy programs. It was nearly impossible to prevent the students from learning the superuser password of the workstations or simply rebooting them in single-user mode. To further complicate matters, many of the computers on the network were IBM PC/ATs running software that didn’t have even rudimentary computer security. Something had to be done to protect student files in the networked environment to the same degree that they were protected in the time-sharing environment.

MIT’s ultimate solution to this security problem was Kerberos, an authentication system that uses DES cryptography to protect sensitive information such as passwords on an open network. When the user logs in to a workstation running Kerberos, that user is issued a ticket from the Kerberos server. The user’s ticket can only be decrypted with the user’s password; it contains information necessary to obtain additional tickets. From that point on, whenever the user wishes to access a network service, an appropriate ticket for that service must be presented. As all of the information in the Kerberos tickets is encrypted before it is sent over the network, the information is not susceptible to eavesdropping or misappropriation.

Kerberos 4 vs. Kerberos 5

Kerberos has gone through five major revisions during its history to date. Currently there are two versions of Kerberos in use in the marketplace.

Kerberos 4 is more efficient than Kerberos 5, but more limited. For example, Kerberos 4 can only work over TCP/IP networks. Kerberos 4 has not been updated in many years, and is currently deprecated. In early 1996, graduate students with the COAST Laboratory219 at Purdue University discovered a long-standing weakness in the key generation for Kerberos 4 that allows an attacker to guess session keys in a matter of seconds. Although a patch for this vulnerability has been widely distributed, some Kerberos 4 implementations are known to be vulnerable to buffer-overflow attacks and no patches have been posted.

219 Incorporated into the CERIAS research center in 1998.

Kerberos 5 fixes minor problems with the Kerberos protocol, making it more resistant to determined attacks over the network. Kerberos 5 is also more flexible: it can work with different kinds of networks. Kerberos 5 also has provisions for working with encryption schemes other than DES. Although algorithms such as Triple-DES have been implemented, their use is not widespread, largely because of legacy applications that expect DES encryption.

Finally, Kerberos 5 supports delegation of authentication, ticket expirations longer than 21 hours, renewable tickets, tickets that will work sometime in the future, and many more options. If you are going to use Kerberos, you should definitely use version 5. IETF is working to revise and clarify RFC 1510, which defines Kerberos 5, and major protocol extensions are expected to follow.

Kerberos Authentication

Kerberos authentication is based entirely on the knowledge of passwords that are stored on the Kerberos Server. Unlike Unix passwords, which are encrypted with a one-way algorithm that cannot be reversed, Kerberos passwords are stored on the server encrypted with a conventional encryption algorithm—in most cases, DES—so that they can be decrypted by the server when needed. A user proves her identity to the Kerberos Server by demonstrating knowledge of her key.

The fact that the Kerberos Server has access to the user’s decrypted password is a result of the fact that Kerberos does not use public key cryptography.220 This is a serious disadvantage of the Kerberos system. It means that the Kerberos Server must be both physically secure and “computationally secure.” The server must be physically secure to prevent an attacker from stealing the Kerberos Server and learning all of the users’ passwords. The server must also be immune to login attacks: if an attacker could log onto the server and become root, that attacker could, once again, steal all of the passwords.

Kerberos was designed so that the server can be stateless. The Kerberos Server simply answers requests from users and issues tickets (when appropriate). This design makes it relatively simple to create replicated, secondary servers that can handle authentication requests when the primary server is down or otherwise unavailable. Unfortunately, these secondary servers need complete copies of the entire Kerberos database, which means that they must also be physically and computationally secure.

Initial login

Logging into a workstation that is using Kerberos looks the same to a user as logging into a regular computer. You type your username and password, and if they are correct, you get logged in. Accessing files, electronic mail, printers, and other resources all work as expected.

What happens behind the scenes, however, is far more complicated. When the workstation’s login process, sshd221, other network daemon, or authentication library (such as PAM) knows about Kerberos, it uses the Kerberos system to authenticate the user.

First, the Kerberos client needs to know where to find Kerberos servers. This can be configured manually on each client (traditionally in the krb5.conf file), or Kerberos servers can be advertised through DNS SRV records. IETF Internet-Draft draft-ietf-krb-wg-krb-dns-locate describes this approach.

With Kerberos 4, the workstation sends a message to the Kerberos Authentication Server222 after you type your username. This message contains your username and indicates that you are trying to log in. The Kerberos Server checks its database and, if you are a valid user, sends back a ticket granting ticket that is encrypted with a cryptographic digest of your password. The workstation then asks you to type in your password and finally attempts to decrypt the encrypted ticket using the password that you’ve supplied. If the decryption is successful, the workstation then forgets your password, and uses the ticket granting ticket exclusively. If the decryption fails, the workstation knows that you supplied the wrong password and it gives you a chance to try again.

220 Public key cryptography was not used because it was still under patent protection at the time that Kerberos was developed. There is a current IETF Internet Draft entitled “Public Key Cryptography for Initial Authentication in Kerberos” that proposes methods for combining public key smartcards with Kerberos. This draft has been implemented in Microsoft’s Kerberos.

221 Patches for OpenSSH to use Kerberos 5 for authentication are available at http://www.sxw.org.uk/computing/ patches/openssh.html. Although Kerberos 4 has also been used with SSH, it’s much more difficult to make the two systems interoperate. Fortunately, the SSH protocol version 2 can use the same security layer (GSSAPI) as Kerberos 5, which simplifies things considerably. The IETF Internet-Draft that covers the combination of these systems is draft-ietf-secsh-gsskeyex.

222 According to the Kerberos papers and documentation, there are two logical Kerberos Servers: the Authentication Server and the Ticket Granting Service. Some commentators think that this is disingenuous, because all Kerberos systems employ a single physical server, the Kerberos Server or Key Server.

With Kerberos 5, the workstation waits until after you have typed your password before contacting the server. It then sends the Kerberos Authentication Server a message consisting of your username and the current time encrypted with your password. The Authentication Server looks up your username, determines your password, and attempts to decrypt the encrypted time. If the server can decrypt the current time (and the value is indeed current), it then creates a ticket granting ticket, encrypts it with your password, and sends to you.223

The ticket granting ticket is a block of data that contains a session key and a ticket for the Kerberos Ticket Granting Service, encrypted with both the session key and the Ticket Granting Service’s key. The user’s workstation can now contact the Kerberos Ticket Granting Service to obtain tickets for any principal within the Kerberos realm—that is, the set of servers and users that are known to the Kerberos Server.

For example, when the user first tries to access his files from a Kerberos workstation, system software on the workstation contacts the Ticket Granting Service and asks for a ticket for the File Server Service. The Ticket Granting Service sends the user back a ticket for the File Server Service. This ticket contains another ticket, encrypted with the File Server Service’s password, that the user’s workstation can present to the File Server Service to request files. The contained ticket includes the user’s authenticated name, the expiration time, and the Internet address of the user’s workstation. The user’s workstation then presents this ticket to the File Server Service. The File Server Service decrypts the ticket using its own password, then builds a mapping between the (UID, IP address) of the user’s workstation and a UID on the file server. Kerberos puts the time of day in requests to prevent an eavesdropper from intercepting a request and retransmitting it from the same host at a later time in a replay attack.

Kerberos offers several security advantages. Passwords are stored on the Kerberos Server, not on the individual workstations, and are never transmitted on the network – encrypted or otherwise. The Kerberos Authentication Server is able to authenticate the user’s identity, because the user knows the user’s password, and similarly, the user is able to authenticate the Kerberos Server’s identity, because the Kerberos Authentication Server knows the user’s password. Other Kerberos services can authenticate the user because the user will present a ticket that is known to have been issued by the Ticket Granting Service because it is encrypted with the target service’s key.

An eavesdropper who intercepts a ticket from the Kerberos Server can’t use it, because it is encrypted using a key (for a Kerberos service or derived from the user’s password) that the eavesdropper doesn’t know.

Authentication, data integrity, and secrecy

Kerberos is a general-purpose system for sharing secret keys between principals on the network. Normally, Kerberos is used solely for authentication. However, the ability to exchange keys can also be used to ensure data integrity and secrecy.

If eavesdropping is an ongoing concern, all information transmitted between the work-station and the service can be encrypted using a key that is exchanged between the two principals. Unfortunately, encryption carries a performance penalty. At MIT, encryption was used for transmitting highly sensitive information such as passwords, but was not used for most data transfer, such as files and electronic mail.

Tickets issued by Kerberos expire after eight hours, a technique designed to prevent a replay attack.224 Thus, after eight hours, you must run the kinit program, and provide your username and password a second time, to be issued a new ticket for the Kerberos Ticket Granting Service.

223 Why the change in protocol? Kerberos 4 attempts to minimize the amount of time that the user’s password is stored on the workstation. Unfortunately, this makes Kerberos 4 susceptible to offline password-guessing attacks against the ticket granting ticket. With Kerberos 5, the workstation must demonstrate to the Kerberos Authentication Server that the user knows the correct password. This is a more secure system, although the user’s encrypted ticket granting ticket can still be intercepted as it is sent from the server to the workstation by an attacker and attacked with an exhaustive key search.

224 A different window may be chosen at some sites.

For single-user workstations, Kerberos provides significant additional security beyond that of regular passwords. However, if two people are logged into the workstation at the same time, then the workstation will be authenticated for both users. These users can then pose as each other. This threat is so significant that at MIT, remote login services were disabled on workstations to prevent an attacker from logging in while a legitimate user was being authenticated. It is also possible for someone to subvert the local software to capture the user’s password as it is typed (as with a regular system).

Getting Kerberos

Kerberos or Kerberos- like security systems are now available from several companies, as well as being a standard part of several operating systems, including Solaris, Mac OS X, and many Linux and BSD distributions. A version of Kerberos 5 has been included in Microsoft Windows from the Windows 2000 release onwards. It is possible (with some effort) to make Kerberos interoperable between Unix machines and Windows platforms.225

225 Note, however, that Microsoft has made proprietary modifications to the Kerberos protocol which have the effect of forcing Windows clients to use Kerberos servers running on Windows servers. In a mixed Unix-Windows environment, the Windows 2000 machine must be the Kerberos server to provide full functionality.

If you need to install Kerberos from scratch, the MIT Kerberos source code is available to United States and Canadian citizens from http://web.mit.edu/kerberos/www/ and to others from http://www.crypto-publish.org. You can also find official updates, patches, and bug announcements. Kerberos has had several bugs discovered, so it is important that you ensure that you are using the most recent version of the code. There is also a free software implementation of Kerberos called Heimdal that is under active development; it is largely compatible with MIT’s Kerberos. You can get Heimdal at http://www.pdc.kth.se/heimdal/. The changes required to your system’s software are substantial if you need to do it yourself; see the documentation provided with Kerberos for details.

Kerberos and LDAP

Kerberos mixes well with LDAP (discussed in the next section). Kerberos can be used to authenticate and secure LDAP queries and updates. Conversely, the LDAP database can store information about users that is more extensive than the data maintained by Kerberos alone, such as the user’s home directory, shell, phone number, or other organizational information. Together, the two services can provide all of the functionality of NIS or NIS+, and they are being increasingly used to do so. Jason Heiss provides a good guide to this process on his page “Replacing NIS with Kerberos and LDAP” at http://www.ofb.net/~jheiss/krbldap/

LDAP is sometimes used to store Kerberos keys. The Windows implementation of Kerberos uses Microsoft’s Active Directory Service (a flavor of LDAP) to store Kerberos keys. Heimdal Kerberos supports this functionality. MIT Kerberos does not, out of concern that sensitive security infrastructure should be centralized at the Kerberos server, rather than distributed via LDAP.

Kerberos Limitations

Although Kerberos is an excellent solution to a difficult problem, it has several short-comings:

Every network service must be individually modified for use with Kerberos

Because of the Kerberos design, every program that uses Kerberos must be modified. The process of performing these modifications is often called “Kerberizing” the application. Typically, to Kerberize an application, you must have the application’s source code, or the application must use a security framework that already incorporates Kerberos, such as PAM (discussed at the end of this chapter).

Kerberos doesn’t work well in a time-sharing environment

Kerberos is designed for an environment in which there is one user per workstation. If a user is sharing the computer with several other people, it is possible that the user’s tickets can be stolen — copied by an attacker. Stolen tickets can then be used to obtain fraudulent service.

Kerberos requires a secure and available Kerberos Server

By design, Kerberos requires that there be a secure central server that maintains the master password database and that is continuously available. To ensure security, a site should use the Kerberos Server for absolutely nothing beyond running the Kerberos Server program. The Kerberos Server must be kept under lock and key, in a physically secure area. If the Kerberos Server goes down, the Kerberos network is unusable.

The Kerberos Server stores all passwords encrypted with the server’s master key, which happens to be located on the same hard disk as the encrypted passwords. This means that, in the event that the Kerberos Server is compromised, all user passwords must be changed.

Kerberos does not protect against modifications to system software (Trojan horses)

Kerberos does not have the local workstation authenticate itself to the user—that is, there is no way for a user sitting at a computer to determine whether the computer has been compromised. This failing is easily exploited by a knowledgeable attacker. These problems are consequences of the fact that, even in a networked environment, many workstations contain local copies of the programs that they run.

Kerberos may result in a cascading loss of trust

If a server password or a user password is broken or otherwise disclosed, it is possible for an eavesdropper to use that password to decrypt other tickets and use this information to spoof servers and users.

Kerberos is a workable system for network security, and it is widely used. But more importantly, the principles behind Kerberos are increasingly available in network security systems that are available directly from vendors.

LDAP

The Lightweight Directory Access Protocol (LDAP) is a low-overhead version of X..500-base directory access service. It provides for the storage of directory information (including, for authentication systems, usernames and passwords) with access and update over a secure network channel. There are two major versions of LDAP. LDAPv2, described in the 1995 RFC 1777, provides no security for passwords unless it is implemented in conjunction with Kerberos. LDAPv3, described in RFC 2251, adds support for SASL (the Simple Authentication and Security Layer, RFC 2222). SASL provides several additional approaches to secure password authentication (including Kerberos!) Furthermore, both the most widely-used open source implementation of LDAPv3 (OpenLDAP 2.x) and the most widely-used commercial implementation (Microsoft’s Active Directory in versions beginning with Windows 2000), support the use of SSL/TLS to secure the entire communication link between client and server, including the authentication process.

On its own, LDAP provides general directory services. For example, many organizations deploy LDAP to organize their employee phone, e-mail, and address directory, or directories of computers on the network. We discuss LDAP in this chapter because it can form the basis of an authentication and network information system, and because it is increasingly being used for that purpose, particularly on Windows and Linux systems.

LDAP: The Protocol

The LDAP server’s data is organized as a tree of entries, each belonging to one or more object classes, and each containing attributes with values. Every entry contains a cn (common name) attribute that distinguishes it from others with the same parent in the tree.

For example, an entry belonging to the “posixAccount” object class includes attributes that specify the user’s full name (cn), login name (uid), user and group id numbers (uidNumber and gidNumber), home directory (homeDirectory), login shell (loginShell), and other user data.

In LDAP terms, a schema is a collection of logically associated object classes and the definitions of their attributes. The posixAccount object class is defined in the network information service schema (nis.schema).

LDAP is a client-server protocol. The LDAP client sends requests to the LDAP server, and receives responses back. Clients can send requests to modify the server’s data store, or to search it and return one or more attributes of a particular entry, or a whole subtree of entries.

Integrity and Reliability

Modern LDAP servers (e.g. Active Directory or OpenLDAP 2.x) provide several important features to ensure the integrity of the data and the reliability of the system:

Data integrity and confidentiality

The LDAP server can accept connections secured by TLS, and can provide end-to-end encryption of the client-server interaction. In addition, TLS makes unauthorized modification of the data stream infeasible.

Server authentication

To support TLS, the LDAP server is assigned a cryptographic public-key certificate, signed by a trusted certifying authority. LDAP clients with the certificate of the certifying authority can assure themselves that they are communicating with the server they intended to communicate with.

Client authentication

LDAP servers can also demand TLS certificates from clients, thus insuring that only authorized clients can query or update the server.

Replication

An LDAP server can replicate entire LDAP datastores onto secondary servers to provide redundancy should the master server fail.

LDAP is a powerful and flexible alternative to NIS or NIS+. Its primary advantages include its ability to store and serve non-authentication data as well as authentication information, and the availability of TLS-secured communication. Its primary disadvantage is that updating the LDAP database is more complex than updating an NIS master, but several tools have been developed to simplify LDAP administration.

Authentication with LDAP

RFC 2307 describes an approach to using LDAP as a network information system. Although this RFC does not specify an Internet standard, its mechanisms are widely used, and a schema to implement them (nis.schema) is included with OpenLDAP 2.x. The schema defines object classes that represent users (posixAccount and shadowAccount), groups (posixGroup), services (ipService), protocols (ipProtocol), remote procedure calls (oncRPC), hosts (ipHost), networks (ipNetwork), NIS netgroups (nisNetgroup, nisMap, nisObject), and more.

Each service that authenticates users must be rewritten to perform an LDAP lookup; this is analogous to the “Kerberizing” process that Kerberos requires. This approach is simple for operating systems like Microsoft Windows that require that all authentications use a vendor-distributed API – very little rewriting of client software is necessary.

For Unix-based operating systems, this approach is inefficient. Instead, two alternatives have been developed, released as open source software by PADL Software Pty, Ltd., and included with most Linux distributions. One, nss_ldap, modifies the C library functions for getting user information (such as getpwent()) to transparently use an LDAP database instead of (or along with) local files, NIS, and so on. Many systems already allow these functions to use a variety of information sources by means of a “name service switch” file (usually /etc/nsswitch.conf). See PUIS, 450-453 for details on configuring authentication using libnss_ldap.

Another approach is to use the PAM framework, discussed in the next section. LDAP authentication is implemented as a PAM module, pam_ldap. Unlike libnss_ldap, pam_ldap provides only user authentication against the LDAP database; it does not distribute other data-base information. If your LDAP server is using the standard nis.schema, adding LDAP authentication to a PAM-controlled service is as easy as adding a line to its PAM configuration file that specifies pam_ldap.so as sufficient for authentication, account verification, and password updating.

Pluggable Authentication Modules (PAM)

Because there are so many ways to authenticate users, it’s convenient to have a unified approach to authentication that can handle multiple authentication systems for different needs. The Pluggable Authentication Modules (PAM) system is one such approach. PAM was originally developed by Sun, and implementations are available for Solaris, FreeBSD, and especially Linux, where most PAM development is now centered. PAM provides a library and API that any application can use to authenticate users against a myriad of authentication systems. Each authentication system that PAM knows about is implemented as a PAM module, which in turn is implemented as a dynamicallyloaded shared library, PAM modules are available to authenticate users through:

o /etc/passwd or /etc/shadow files o NIS or NIS+

o LDAP

o Kerberos 4 or 5

o An arbitrary Berkeley DB file226

226 If that’s not enough layers for you, some applications, such as SMTP authentication in sendmail or access to mailboxes managed by the Cyrus imapd server, use the Cyrus SASL (simple authentication and security layer) authentication library, which can authenticate users with a separate database or through PAM! It is not inconceivable that you might find SASL using PAM using LDAP to authenticate a user’s imap connection.

Each PAM-aware service is configured either in the /etc/pam.conf file or, more commonly, in its own file in the /etc/pam.d directory. For example, the PAM configuration file for the ssh server in Linux distributions is

/etc/pam.d/sshd. A service named “other” is used to provide defaults for PAM-aware services that are not explicitly configured. Here is an example of a PAM configuration file for sshd on a Linux server:

auth required /lib/security/pam_env.so

auth sufficient /lib/security/pam_unix.so

auth required /lib/security/pam_deny.so

account required /lib/security/pam_unix.so

password required /lib/security/pam_cracklib.so retry=3

password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow

password required /lib/security/pam_deny.so

session required /lib/security/pam_limits.so

session required /lib/security/pam_unix.so

The “auth” lines describe the authentication process for this service, which proceeds in the order specified. Modules marked “required” must run successfully for authentication to progress — if they fail, the user is considered unauthenticated and generally will be denied access. Multiple “required” modules can be specified; in these cases, all of the modules must run successfully. Modules marked “sufficient,” if run successfully, are sufficient to authenticate the user and end the authentication process.

In this example, the first module run is pam_env, which optionally sets or clears environment variables specified in /etc/security/pam_env.conf. This module is required — it must run successfully for authentication to proceed. The next module run is pam_unix, which performs authentication with the usual Unix password files, /etc/passwd and /etc/shadow. If this succeeds, it is sufficient to authenticate the user, and the process is complete. The final authentication module is pam_deny, which simply fails, ending the process with authentication unsuccessful.

This particular configuration file will also enforce any account aging or expiration rules of the system, and set resources limits on the user’s sshd session. If sshd provided a password-changing function, this configuration file would also prevent the user from changing his password to an easily guessable one, and store passwords in /etc/shadow encrypted by the MD5 cryptographic hash function.

The PAM subsystem can be configured in a number of different ways. For instance, it is possible to require two or three separate passwords for some accounts,227 combine a biometric method along with a passphrase, or pick a different mechanism depending on the time of day. It is also possible to remove the requirement of a password for hard-wired lines in highly secured physical locations. PAM allows the administrator to pick a policy that best matches the risk and technology at hand.

227 This is of questionable value when the same user holds all of the passwords. This approach can be valuable when the passwords are assigned to different users, so that any login requires two or more people, and creates a “witness” trail.

PAM can do a lot more than authentication, as the examples above suggest. One of its strengths is that it clearly delineates four phases of the access process: verification that the account is viable for the desired service at the desired time and from the desired location (the account phase), authentication of the user (the auth phase), updating passwords and other authentication tokens when necessary (the password phase), and setting up and closing down the user’s session (the session phase), which can include limiting resource access and establishing audit trails.