Chapter 6: Authentication and Key Distribution | Internet & Intranet Security

Team-Fly

In this chapter, we overview and briefly discuss two basic building blocks for network security in general, and Internet and intranet security in particular: authentication and key distribution. More specifically, we address authentication in Section 6.1 and key distribution in Section 6.2. Note that many authentication schemes, such as one-time passwords and challenge-response mechanisms, are inherently strong but still vulnerable to specific attacks (e.g., session hijacking attacks). One possibility to protect against some of these attacks is to combine authentication and key distribution, and to use the distributed keys to transparently authenticate or encrypt all data that are transmitted after authentication has taken place. An attacker who does not have the correct keys is not able to hijack the session accordingly. Also note that this chapter focuses on the fundamentals, and that specific authentication and key distribution systems (e.g., the Kerberos system) will be explored in Chapter 16.

6.1 AUTHENTICATION

In general, authentication refers to the process of verifying the claimed identity of a principal. Authentication results in authenticity, meaning that the verifying principal (i.e., the verifier) can be sure the verified principal (i.e., the claimant) is the one he or she claims to be.

It is common to divide the techniques that are used for authentication into four categories, depending on whether a technique is based on:

Something the claimant possesses (proof by possession);
Something the claimant knows (proof by knowledge);
Some biometric characteristics of the claimant (proof by property);
Somewhere the claimant is located (proof by location).

As of this writing, it is commonly agreed that the first three categories are categories of their own, whereas it is not commonly agreed that the fourth category is also a category of its own. Because of its increased importance in contemporary security architectures, however, it is considered to be a category of its own in this book. Some exemplary authentication techniques are overviewed next. Note that the techniques are not mutually exclusive, and that several techniques can be combined in a proper design.

6.1.1 Proof by Possession

In a proof by possession, the claimant proves his or her identity by proving possession of some physical token. On the verifier side, the proof can be verified manually or automatically. In the second case, a corresponding detector (hardware or software) is required. Examples of physical tokens are:

Physical keys;
Identification cards;
Magnetic stripe cards;
Smart cards;
USB tokens.

Physical keys have been in widespread use for at least a couple of centuries, whereas all other examples itemized above are relatively new. For example, the use of smart cards and USB tokens to store cryptographic keys has evolved only in the last couple of years and is still considered to be in its infancy.

The major advantage of a proof by possession is that it is very simple and straightforward to use by human beings, whereas the major disadvantages are related to the production, distribution, and management of the physical tokens and the corresponding detectors (if the proofs must be verified automatically). The result of these disadvantages are difficulties in large scale deployment and operational costs that are often prohibitive. Consequently, proofs by possession are seldom used in networked and distributed systems.

6.1.2 Proof by Knowledge

In a proof by knowledge, the claimant proves his or her identity by proving knowledge of some secret information (e.g., a password or a cryptographic key). This information, in turn, may either be static or dynamically changing in time. Roughly speaking, static information can be used to implement weak authentication mechanisms, whereas dynamically changing information can be used to implement strong authentication mechanisms. Note that in either case, the secret information may be too large or include too much entropy to be kept in memory by human users. Consequently, the use of some auxiliary technologies to store and make available the secret information is common today. Examples include magnetic-stripe cards, smart cards, and USB tokens. Also, the use of personal digital assistants (PDA) to store secret information (possibly in encrypted form) is widespread. Note, however, that contrary to the use of these technologies in a proof by possession, these technologies are only used to extend the capacities of human users in a proof by knowledge. The existence of the physical device is not verified. Obviously, it is possible and makes a lot of sense to combine a proof by possession with a proof by knowledge. For example, if we want to withdraw money from an automatic teller machine (ATM) we usually insert an ATM card into the machine and enter a personal identification number (PIN) into the terminal associated with the machine. In this example, the insertion of the ATM card represents a proof by possession, whereas the fact that the user enters a PIN represents a proof by knowledge.

Static Information

Examples of static information that may be used in a proof by knowledge include PINs, passwords, and passphrases. As of this writing, passwords are by far the most widely deployed authentication mechanisms used in computer networks and distributed systems. This is because they are simple to implement and use. Unfortunately, however, passwords and the way they are used today have two major security problems:

Users tend to select passwords that are easy to remember. Consequently, such passwords are not randomly distributed and are easy to guess [1, 2]. Password guessing is the process of correctly guessing the password of a legitimate user. Dan Klein analyzed the feasibility of password-guessing attacks for approximately 15,000 user accounts in 1990. As a result, he found that he could guess 2.7% of the passwords in the first 15 minutes and 21% within the first week [3]. It is assumed that these numbers have not changed much since their original publication in 1990. To make things worse, there are many tools available on the Internet that can be used for password-guessing attacks (e.g., LOphtcrack).
The transmission of passwords (which may be well chosen or not) is exposed to passive eavesdropping and subsequent replay attacks. This is because the passwords are often transmitted in the clear. Also, if passwords are not transmitted in the clear but "encrypted" using a well-known one-way function, it is still possible to launch a password guessing attack by simply "encrypting" password candidates with the one-way function and checking whether the result matches the string that has been transmitted at first place.

Obviously, these security problems do not only apply to passwords and are equally true for any other static information that may be employed in a proof by knowledge (e.g., PINs or passphrases). Consequently, the use of static information in a proof by knowledge is not suitable anymore in contemporary computer networks and distributed systems. In fact, the information is too easy to intercept and reuse. While this vulnerability had been known for a very long time, it was not until 1994 that it was demonstrated on a large scale with the discovery of planted password collecting routines at some critical points within the Internet.^[1] We have mentioned this vulnerability and the feasibility of corresponding eavesdropping attacks in the preface and Chapter 3. To improve the level of security of a proof by knowledge, we must use information that is dynamically changing in time.

Dynamically Changing Information

The basic idea of using dynamically changing information in a proof by knowledge is that each authentication process uses a unique piece of authentication information, and that this piece of authentication information cannot be (mis)used at some later point in time. Consequently, if an attacker is able to eavesdrop on an authentication protocol execution and grab the relevant authentication information, he or she will will not be able to (mis)use this information in a replay attack. The information will not be valid a second time.

The use of dynamically changing information is not a new idea. In fact, we have been using transaction authentication numbers (TANs) for a long time. In short, a TAN is a piece of authentication information that can be used for one single authentication process or transaction. It is randomly chosen by the verifier and provided to the claimant using some secure channel (i.e., a trusted courier). The use of TANs is simple and straightforward, and as such there are many applications for them. For example, banks have been using TANs (together with passwords) to authenticate users and account owners. Similarly, many e-government applications can provide client authentication using TANs that are provided to the citizens using certified mail.

If the number of authentication processes or transactions increases beyond a certain threshold, the generation, distribution, and management of TANs becomes very difficult (i.e., the use of TANs does not scale). In this situation, it is generally a good idea to use cryptographic techniques to come up with authentication schemes that make use of dynamically changing information [4]. Some examples are overviewed and briefly discussed next.

One-Time Password Schemes As its name suggests, a one-time password is a password that can only be used once, meaning that it can only be used for one single authentication process. As such, a one-time password is conceptually similar to a TAN. The major difference is that TANs are generated randomly by the verifier and distributed to the claimant using some secure channel, whereas one-time passwords are typically generated dynamically and deterministically by the claimant and verifier.

Against this background, a one-time password scheme is an authentication scheme that uses one-time passwords. There are many one-time password schemes and corresponding systems available today:

SecurID tokens^[2] as marketed by RSA Security, Inc., are the most important and most widely deployed one-time password system in use today. Roughly speaking, each SecurID token contains a cryptographic processor that implements the DES, a secret DES key, a clock that is synchronized with the verifier (i.e., an ACE/server), and a small display. The one-time passwords are generated by having the token read out the time from its clock and encrypt the corresponding value with the secret DES key. At each time interval (e.g., each minute), the SecurID token generates a new one-time password and shows it on its display. If the holder of the SecurID token (i.e., the user) wants to authenticate himself or herself, he or she reads from the token's display the currently valid one-time password and types it in at the login prompt (together with a constant password).
An alternative one-time password scheme that does not require the implementation of a cryptosystem was originally proposed by Leslie Lamport in the early 1980s [5]. In this scheme, the claimant (i.e., the user) begins with a secret password pw. A one-way function h is then used to generate a sequence of t one-time passwords: pw, h(pw), h(h(pwd)), …, h^t(pw). This sequence is used by the claimant in the reverse order, meaning that the one-time password for the ith authentication process, 1 ≤ i ≤ t, is defined to be h^t−i(pw). This password is used by the claimant to authenticate himself or herself to the verifier. Lamport's one-time password scheme was implemented at Bell Communications Research (Bellcore) in a one-time password system called S/Key [6].^[3] S/Key uses MD4 as a one-time function. More recently, the use of MD4 was replaced with MD5 in a similar system called One-Time Passwords in Everything (OPIE) developed at the U.S. Naval Research Laboratory (NRL). S/Key and OPIE both conform to the one-time password system specified in [7].

In addition to SecurID tokens, S/Key, and OPIE, there are many other one-time password systems commercially or freely available on the Internet.

Challenge-Response Mechanisms One-time password schemes and corresponding systems are simple and straightforward. The major advantage is that they do not require an interaction between the claimant and the verifier. The claimant simply provides a piece of authentication information to the verifier, and the verifier can verify the validity of it (without interacting with the claimant). The major disadvantage, however, is that the claimant and verifier must be synchronized in one way or another (e.g., they must have synchronized clocks).

Like one-time password schemes, challenge-response mechanisms are authentication schemes that make use of dynamically changing information. Unlike one-time password schemes, however, challenge-response mechanisms require the claimant and verifier to interact but generally do not require them to be synchronized. In a challenge-response mechanism, the verifier provides the claimant with a challenge (i.e., a randomly chosen number), and the claimant must compute and provide a valid response for this challenge. Again, there is some sort of cryptographic secret (e.g., key) that must be known on either side to compute and verify the claimant's response.

For example, a digital signature scheme can be used to implement a simple challenge-response mechanism. If the claimant holds a private key and the verifier holds a corresponding public key (or public key certificate), the verifier can challenge the claimant with a randomly chosen number and the claimant can respond with the digital signature for that number. Because the verifier holds the public key (certificate), he or she can easily verify the validity of the claimant's response. Note, however, that this exemplary challenge-response mechanism is far too simple to be used for real applications. It would be too dangerous for a claimant to digitally sign arbitrary values that claim to be legitimate challenges. What would happen, for example, if the claimant were challenged with a one-way hash value computed from the message string "I owe you $1,000"? In this case, the claimant would respond with the digital signature for a message he or she would not have signed in the first place. Consequently, the design and analysis of challenge-response mechanisms are very tricky and must be considered with care.

There is a special class of challenge-response mechanisms and corresponding protocols that have a property called zero-knowledge. Using such a protocol, a claimant can proof knowledge of a secret (e.g., a cryptographic key) while revealing no information whatsover about the secret [8]. It is possible and very likely that zero-knowledge protocols will become important and widely used in the future.

6.1.3 Proof by Property

In a proof by property, the claimant proves his or her identity by proving some biometric characteristics. The biometric characteristics, in turn, are measured and compared with a reference pattern by the verifier. Historically, the first biometric characteristics that were used for authentication were fingerprints. Today, it is possible to use other characteristics, such as facial images, retinal images, and voice patterns. In fact, the recent past has shown an increased interest in biometric technologies and applications.

In practice, the use of biometric characteristics to authenticate users in computer networks and distributed systems is difficult because:

Foremost, all terminals and end systems must be equipped with devices that are able to read biometric characteristics from users. This is difficult and expensive to deploy.
All communication lines between the readers and the verifier must be made secure (i.e., physically or cryptographically protected).
The use of biometric characteristics also requires some form of live testing.
There are still some privacy concerns related to the widespread use of biometric technologies and applications.

Because of these difficulties in practical deployment, the use of biometric characteristics is still not widespread today.

6.1.4 Proof by Location

In a proof by location, the claimant proves his or her identity by proving his or her current location. There are several incarnations of this idea:

For example, a dial-back system implements a proof by location, because the claimant is called back by the verifier using some defined number (i.e., a number that is bound to a specific network access point).
Similarly, an address-based authentication scheme as employed, for example, by the BSD UNIX r-tools (rlogin, rsh, and rcp) also implements a proof by location. Address-based authentication does not rely on sending passwords across the network, but rather assumes that the identity of the source can be inferred based on the network address from which packets arrive. The basic idea is that each host stores information that specifies accounts on other hosts that should have access to its resources. Each host may have a file named /etc/hosts.equiv containing a list of trusted hostnames. Users with the same username on both the local and the trusted host may use the r-tools without having to supply a password. Individual users may set up a similar private equivalence list with the .rhosts file in their home directories. Each line in this file may contain a host-name and a username separated by a space. An entry in a user's remote .rhosts file permits the user who is logged into the system specified by hostname to log into the remote system without having to supply a password. Instead of logging into the host, the user can also remotely execute commands or copy files. Note that the idea of trusted hosts is no general solution to the authentication problem in computer networks and distributed systems, and trusted hosts may even pose more serious security threats. The point is that host authentication mechanisms can always be defeated, and if an attacker is able to break into an account in a host that is trusted by other hosts, the users' accounts on these other hosts are usually compromised as well. The use of .rhosts files poses an additional security threat because the system administrator is, in general, unable to exclusively control access to the system via the r-tools. Users are likely to tailor their .rhosts files more for convenience than for security. Depending on the environment, address-based authentication may be more or less secure than sending passwords in the clear. In either case, it is more convenient, and it is therefore the authentication mechanism of choice in many networked environments.
In a more sophisticated location-based authentication scheme, the verifier may check the geodetic location of a claimant. The corresponding information may be provided, for example, by the Global Positioning System (GPS). The use of GPS signals for location-based authentication has been pioneered by a company called CyberLocator.^[4] At the time of this writing, it is still too early to tell whether the GPS-based authentication scheme will withstand a more serious analysis or attack.

In any case, it is possible and very likely that information about the current location of a user will play an increasingly important role in future user authentication schemes.

^[1]Compare CERT Advisory CA-94:01, "Ongoing Network Monitoring Attacks," 1994.

^[2]http://www.rsasecurity.com/products/securid/index.html

^[3]ftp://thumper.bellcore.com/pub/nmh/skey

^[4]http://www.cyberlocator.com

Team-Fly