Security and the OSI Model

Network security encompasses several orthogonal services, including user authentication, message authentication, and confidentiality, which may be used together or separately. Authentication is a term that has at least two meanings in the context of network security.

One type of "authentication" in network protocols involves the use of cryptographic techniques to "sign" a message, in such a way that only the signing party could have sent it. Certain applications only need to know that the message has not been altered in transit, and it is not important to keep the "protected" messages secret. In such cases, the application programmer, or the person who has deployed and configured the system, has deemed that the application is not vulnerable to eavesdropping. The message authentication service can be used to provide for services such as non-repudiation, to guarantee that only a person who knew the key could have sent a given message. In practical terms, non-repudiation can never be proven, since if I were accused of sending a digitally signed packet, my logical defense would be to assert that my key had been compromised and that someone else had actually sent the message.

The "protocols" that provide message authentication are primarily one-way hash functions, also known as message digest functions. The output of such functions is variously called an Integrity Check Value (ICV), or a Message Integrity Code (MIC) or a Message Authentication Code (MAC), depending on the context. Examples of such algorithms will be given later in this chapter. The input to such functions typically consists of the data to be protected, plus a key (or a number derived from a key), so that only someone with knowledge of the key could have computed the resulting hash value. Without using a keyed hash function, anyone could save a copy of a valid frame, change the data, and re-compute a hash value that matches the new data. Such a fabricated frame would be accepted by the receiver if the only validity check was to verify the hash value.

Another aspect of authentication is used to determine how and when users may access a network and its resources. Via a suite of protocols and services known collectively as Authentication, Authorization, and Accounting (AAA), authorized users may be allowed access to a network and its resources. The AAA function is so important that (as of early 2003^[7] ) the IETF has an entire WG devoted to standardizing just these related aspects of security.

^[7] In the IETF, a WG only exists long enough to solve whatever problem(s) it was created to solve. Once a solution is at hand, the WG is typically disbanded.

Functionally, many AAA protocols have their roots in performing network access control functions for dial-up point-to-point networks. For example, a user of a certain ISP must be identified as a valid customer before he or she will be granted access to the ISP's network. The user might dial in to any of a number of the ISP's Network Access Servers (NAS; e.g., dial-in access concentrators), which all must be able to tell if this user is valid. The NAS devices rely on AAA protocols to provide an interface to a networked database of userIDs and their associated credentials. This networked database enables each NAS device to validate any user at any time, without needing to keep its own local copy of the entire credentials database.

The protocols most commonly associated with AAA services are the Remote Access Dial-In User Service (RADIUS; RFC-2865) and Diameter (not an acronym; a new protocol that some people think will eventually supplant RADIUS), but other protocols such as the Common Open Policy Service (COPS; RFC-2748) and the Simple Network Management Protocol (SNMPv3; STD-62; RFCs 3411 3418) may also be employed.

Early (proprietary) protocols in this space included Terminal Access Controller Access Control System (TACACS) and TACACS+, both of which were defined by cisco systems and supported on many vendors' terminal servers, and they were also used to protect access to terminal-oriented applications, such as the user interfaces of routers, and to provide access control for terminal servers. These early protocols, and many of their progeny, were used to provide a common interface by which various devices could query a server that contained user-based credentials (at a minimum, this would be a database of userIDs and their associated passwords). The follow-on protocols (e.g., RADIUS and Diameter) were improvements in the degree of extensibility and in the set of services that were offered (e.g., secure exchanges with the back-end AAA server(s)) to remove the chance of a man-in-the-middle attack rogue users could masquerade as an authentication server once they have observed an unprotected protocol exchange between the authentication server and any network access device.

The deployment of protocols such as RADIUS was driven by the fact that all of a network's Network Access Servers^[8] (NAS devices) needed to have access to the complete set of userIDs and authentication credentials. Now, if a corporation had only one such NAS device, there would be no need for RADIUS or its friends, since the access concentrator would be able to store all that information locally (if it had adequate storage space, that is). However, once the organization deploys their second access concentrator, they will have to keep an up-to-date list of all the userIDs and related credentials on both concentrators. After all, they do not know to which concentrator the user will dial. Any organization that has more than a handful of access concentrators would benefit from being able to split the userID/credential management from the management of the access concentrators. That is one role of AAA protocols, to provide NAS devices with a common interface to a back-end database of user credentials. Any user can dial in to any NAS device, and be an equally valid user on every device to which he or she connects.

^[8] The first example of such devices was access concentrators for dial-up modems.

The IEEE 802.1X-2001 standard leveraged this back-end infrastructure in the context of the "Port-Based Network Authentication" standard. In many ways, Ethernet bridges (i.e., layer-2 switches) are like dial-up NAS devices, since the user is connected by a point-to-point link. If it supports IEEE 802.1X, an Ethernet bridge (i.e., layer-2 switch) can use the same back-end authentication database that already existed to support the dial-up users to determine if a user has a legitimate right to access a given network. In fact, if they already had a dial-up account, the IT department may not need to do anything to create new records for this user in the AAA database. The IEEE 802.1X-2001 standard does not mandate RADIUS support, but that is a protocol that is commonly employed in today's networks. Newer protocols (e.g., Diameter) may eventually displace RADIUS for the server-side (i.e., back-end) authentication engine functionality.

Open Access Network Requirements

It's interesting to note that the reason why IEEE 802.1X was developed was to support network authentication for IEEE 802.3-based network access from shared places like computer labs and conference rooms (e.g., at universities) so that only valid users could access the network from those locations. This type of access control is also useful in corporate settings to ensure that only valid users can attach to the corporate network. However, it turns out that there was a big ease-of-use problem with the wired public-access usage scenario, in that users needed to drag along a patch cable in order to connect to the network. In addition, there was a nontrivial capital expenditure involved in wiring a classroom, dormitory, lecture hall, or library with network jacks. The primary source of the expense was (and is) the wiring itself, and the labor to install it, since the cost per port of Ethernet switches (bridges) has dropped so low as to be negligible when budgeting for such a project.

The need for access in public spaces, and in classrooms, was great, but in a practical sense, the usability of this form of "mobile" computing just wasn't suited to the requirements. The laptops were indeed mobile, but they were anchored to these network jacks, which constrained movement to within a small radius around the jack, dependent on the length of the user's patch cord.

It's ironic that the real demand for IEEE 802.1X-based authentication (and key management) has come from a LAN technology that was in its infancy when the IEEE 802.1X TG was completing its work. There are a few cursory mentions of IEEE 802.11 in the IEEE 802.1X-2001 standard, but it almost certainly would have been written differently if the TG had known that the "killer app" for their technology was going to be IEEE 802.11, not IEEE 802.3. (It is not the case that the authors of IEEE 802.1X would have known in 2001 that their technology was going to become the basis for the future authentication and key management schemes in IEEE 802.11, since at the time, the degree to which IEEE 802.1X was going to be leveraged was unknown.)

The design center for IEEE 802.1X authentication was clearly switched (i.e., bridged) IEEE 802.3 wired LANs. The operation of IEEE 802.1X to provide secure authentication and secure key exchange in shared media LANs was not thoroughly described. This is why the IEEE 802.11i TG has had to specify things like the four-way handshake…there was no secure way to do authentication or key exchange in shared-media LANs, especially shared-media LANs in which eavesdropping is absolutely trivial.

The need for user authentication is just as legitimate in a LAN scenario as it is in a dial-up WAN scenario. The use of IEEE 802.1X is not limited to Ethernet; it can be used with any LAN technology, although it is not particularly well-suited to operation over shared-media LANs such as IEEE 802.11. The IEEE 802.11i TG has needed to enhance the base IEEE 802.1X protocol(s) to support secure user authentication over a shared medium LAN.

Finally, confidentiality service is typically provided by using cryptographic algorithms to encrypt the data, using either secret-key (properly called "symmetric" algorithms) or public-key ("asymmetric") algorithms. In the former type of algorithm, there is a key exchange that limits knowledge of the key to the parties that negotiated it. In the latter type of algorithm, each party has a public and private key, and the public key is made available to anyone who wants to communicate with this party.

By virtue of some deceptively simple arithmetic, the party that possesses the private component of the key can encrypt data that can only be decrypted with the public component of the key, and vice versa: the public key can be used to encrypt the key such that only the holder of the private key can decrypt it. Because this cryptosystem uses two different keys one of which is public, earning it the moniker "public key" cryptography to establish a cryptographic "connection" between two machines,^[9] it is also known as an "asymmetric" cryptosystem, since it uses different keys in each direction. Symmetric cryptosystems use only one key for a connection, and the key must be kept secret since anyone with possession of the key can decrypt the data.

^[9] More formally, such a cryptographic connection is often referred to as a "security association."

Despite the apparent advantages of public-key cryptography, the one important quality that it lacks is speed. In most real cryptosystems, public key cryptography is used to establish a connection and to derive a symmetric session key, which is then used to encrypt and decrypt data with high performance. Public key cryptosystems, as they are usually known, implicitly provide a certain level of authentication (provided that the private keys are kept secret…if they are compromised, then whoever knows the private key can impersonate the user who is properly associated with the public key).

In secret-key ciphers, one key may serve only two parties, in which case it is known as a "pairwise" key, or it could be used by multiple parties, in which case it is known as a "shared" key. The terms "pairwise" and "shared" are generally used in the context of unicast confidentiality, whereas multicast or broadcast traffic is generally protected by a "group" key. It is possible that a pair of stations may be in possession of a pairwise and a group key at the same time, using the appropriate key based on the type of traffic that is being sent at any given instant.

There are many types of secret-key algorithms, including stream-oriented and block-oriented ciphers. The best example of a stream-oriented cipher is RC4, while examples of block-oriented ciphers are the Data Encryption Standard (DES), Triple-DES, and the Advanced Encryption Standard (there are many others as well).

The degree of control over which data is encrypted, and how it is encrypted, varies with the layer at which encryption is performed. In general, it can be assumed that each layer in the OSI model has had some form of security service defined. Typically, real systems will only apply security protection to a small number of layers, depending on the application's requirements. Moreover, certain services (e.g., message authentication) may be a better fit at certain layers than at others.

The Physical Layer

For decades (i.e., since the mid-1970s, at least), there have been Physical layer devices that organizations such as banks and governments used to encrypt sensitive or valuable data over point-to-point links. For example, a Physical layer security device might be designed to encrypt an entire bit stream between two WAN (typically) devices, one bit at a time, including any null data that may be transferred between actual data frames.

There is not necessarily any ability to encrypt only the most sensitive portions of the data stream, or even to limit the encryption to only data frames, and not the inter-frame null data that is often present to maintain clock synchronization. In some cases, it may actually be preferable to simply encrypt the entire bit stream, since an observer would not be able to tell the difference between an idle line and a line that was carrying protected data. To an encryption device operating at the Physical layer, all bits are probably equally important. As one considers progressively higher layers in the protocol stack, one observes increasingly finer control over how data will be encrypted, and over which data will be encrypted.

The Data Link Layer

At the Data Link layer, a device may be able to limit encryption within an entire LAN, or only among a set of MAC addresses. Optionally, it may be possible to protect broadcast and multicast frames differently than unicast frames. Note, however, that the frames cannot be completely encrypted, since the header at the front must be preserved (otherwise, the MAC addresses would not be available to the intermediate bridges (i.e., layer-2 switches), and even an end device would never be able to tell that a frame was meant for it).

Historically, encryption at the Data Link layer has not been much of an issue, since there are probably many router hops between a sender and receiver, and protecting each hop individually is not feasible. Furthermore, since every intermediate device would have to have the ability to decrypt the data it receives (so it can be re-encrypted on the outgoing interface), each of the intermediate devices is also effectively a wiretap, since it has access to the unencrypted frames.

The reason why this chapter is in this book, however, is that WLANs are a new form of LAN that is inherently shared, and fundamentally vulnerable to eavesdropping. In the original IEEE 802.11 specification, the standard specified a set of algorithms known as Wired-Equivalent Privacy (WEP), which was not designed to provide bulletproof protection; rather, the designers were only attempting to make eavesdropping on WLANs approximately as difficult as on wired LANs.

As we will see later, for a variety of reasons, WEP turned out to be an inadequate solution to that problem, and a new security paradigm is being finalized that will hopefully provide a trustworthy foundation for WLANs. The goal is to make WLAN security literally robust, which will actually supersede the security of a wired LAN in some ways.

Security in other LAN media is becoming an increasingly interesting topic, since the IEEE 802.3ah (Ethernet in the First Mile) group needs some sort of security to prevent their point-to-multipoint Ethernet-based access networks from leaking frames. Without security at the Data Link layer, it would be possible for a given customer to receive data that was meant for another customer. The IEEE LMSC Sponsor Executive Committee (SEC) has convened a Link Security Study Group to consider whether it would be worthwhile to define a security architecture that would apply uniformly across all LAN media; as of the March 2003 timeframe, this Executive Committee Study Group was moved into IEEE 802.1 WG. (The IEEE 802.10 standard may or may not be sufficient for this purpose; however, that WG is in a state that the IEEE LMSC refers to as "hibernation," which limits it to servicing interpretation requests made regarding the IEEE 802.10 standard(s) it has produced. As it was in this dormant state, there was not any active membership that could have worked on the new security architecture.)

The Network Layer

IP operates at the Network layer, and for IP, the Internet Protocol Security (IPSec) suite of protocols enables encryption between IP addresses (IPSec works with either IPv4 or IPv6), and supports authentication, either integrated with encryption or alone. In conjunction with the Layer 2 Tunneling Protocol (L2TP), or in conjunction with IP-over-IP tunneling or IPsec "tunnel mode" tunneling, IPsec may be used to provide VPN services.

At the Network layer, it is possible to encrypt traffic between two IP addresses, either for all traffic between them, or perhaps only for certain TCP- or UDP-based Application-layer protocols (although this filtering based on Transport-layer port is not, strictly, a Network layer operation, the encryption is carried out at the Network layer). As with the Data Link layer, the Network layer header information must be exposed to public view so that the packet can be properly delivered. However, at the Network layer, the situation is slightly more complex, since the Network layer header may contain certain "mutable" fields, which is a fancy word for "changeable," and these fields must be protected differently^[10] compared to "immutable" fields, such as the Network layer Source and Destination addresses, which may not change en route. Some Data Link layer protocols also have mutable headers, and if they must be protected, then the Data Link layer encryption algorithms will be designed to do so.

^[10] A field like the Time to Live (TTL) is expected to change in transit. Each hop decrements it. This is normal, and a security algorithm should not fail if the TTL at the destination is different than it was at the source. There are other fields in the Network layer header that are also mutable, but the easiest one to describe is the TTL field.

The exact definition of which Network layer header fields are mutable and which are immutable will differ between various Network layer protocols, but any security applied at the Network layer will need to accommodate the differences between mutable and immutable header fields. In the case of IPsec, the Authentication header protects the immutable fields by including them as input to its message digest calculation. If any of these fields change, or if the data itself is modified in transit even by only a single bit then the receiver's calculated integrity check value (ICV) will not match the ICV that was included in the packet after being calculated by the sender.

The Transport Layer

Many people use VPNs that are effectively unprotected packets tunneled through Secure Shell (SSH) connections, at the Transport layer. The security negotiations and the resulting encryption are provided by the VPN protocol itself, but the application being tunneled is unaware of the tunnel (except, perhaps being aware that the MTU of that link is smaller than it otherwise might be, due to the presence of the VPN header(s) that were added to the packet).

Other security schemes at the Transport layer include standards such as the Secure Sockets Layer (SSL) or its progeny Transport Layer Security (TLS), which provide for application-driven security services, for example to protect passwords or credit card information when accessing a secure Web site. At the Transport layer, one can employ SSL/TLS to enable encryption of entire sessions, or perhaps just to protect the information that the application developer believes should be kept confidential.

The Application Layer

When the application dictates the usage of encryption, it is likely to be applied judiciously only where it is needed, whereas lower-layer approaches tend to be increasingly heavy-handed as one descends the protocol stack, and encrypt data as if it were all equally important. Taken to the extreme, Physical layer devices encrypt every bit that goes onto the wire.

In some cases, networked applications may include encryption and/or authentication services as an integral part of their operation. In general, while it is probably true that an application developer best knows the requirements for protecting (certain parts of) the application's data, and while it is probably also true that the security protection at the Application layer can be far better targeted at exactly what needs to be protected, it is unfortunately sadly true that the application programmer may not have adequate expertise in network security to put together a solid security architecture for his or her application.

From a user's perspective, the most familiar instance of an Application-layer security protocol would probably be "secure HTTP" (in a URL, the customary "http://..." is replaced by "https://..." for those Web sites that are protected by SSL encryption^[11] ). Any time you buy something on the Web, or log in to manage your checking account, the URL is probably indicating secure HTTP. When https is in use, the "padlock" icon in the Web browser is typically in the closed position. Whether or not https is an Application-layer protocol (http) that is simply taking advantage of Transport-layer security mechanisms (i.e., SSL or TLS), or is its own secure Application-layer protocol is mostly a semantic question. From the user perspective, https certainly appears to be a secure Application-layer protocol, and interpreting it that way is completely legitimate.

^[11] SSL was invented by Netscape. The IETF created Transport-Layer Security (TLS), a standards-based version of SSL, effectively.

Well-known encryption and message digest algorithms are not likely to be broken, since they have been subjected to extensive peer review. Most attacks on networked applications manage to find the weakest part of the system and exploit that weakness. Systems with random number generators that were insufficiently random have been compromised. Attacks have been successfully mounted against systems with weak authentication schemes (strong authentication technology can be deployed in risky ways). Systems that make poor choices of keys and initialization vectors have been breached. The list goes on. People have written entire books on the weaknesses of various systems, detailing how they have been exploited.

The state of the art in network security has advanced quite far (although perfection is probably an unobtainable goal), but there are no guarantees that a programmer will put together the pieces in a way that has no weaknesses (obvious or subtle), or that a network manager will unwittingly deploy the system's components in a way that leaves the system vulnerable to attack. The fact is that most security systems are not broken directly. It is usually far easier to compromise a key than it is to break through a door. One might imagine that network security is one aspect of the construction of a structure, perhaps an exceptionally nice, well-balanced hammer. The fact that a superb hammer was used to build a structure is irrelevant if poor-quality nails and wood were used. In security, the whole system needs to be securely designed and securely deployed (and securely operated) to create the desired barrier to attack.

A W0rd 0n P@ssw0rdz

From an end-user's perspective, the main (only?) difference between a system with security and a system without security is often just a password. Behind the scenes, there are many ways that a system can be secured, but these ways are most often invisible to end users. End users only see the user interface that prompts them for their userID and password, or whatever credentials are required for access to a system (e.g., smart cards, biometrics (e.g., retina or fingerprint scans), etc.), but those forms of credentials are far less common than the password. Unfortunately for the system operators, most people tend to be very bad at choosing passwords. Therefore, the security aspects (e.g., encryption protocols, authentication algorithms, etc.) of the secured system are not its weakest link; rather, the weak link is the user's inability to choose good passwords.

Imagine that the system administrator has designed a very secure system, loaded with strong encryption and all sorts of access controls, perimeter defenses, physical access control, and so forth, but has users who can't remember their passwords, so they leave them written on a scrap of paper kept strategically near their monitors. Now imagine a security-conscious individual who builds a house with solid steel walls, Kevlar windows, and an alarm system with motion detectors, then surrounds the house with thorny shrubbery, and a moat, and installs a high-tech door that is quite like the door to a bank vault, but whose teenager then forgets to lock the door when he goes out. Just as a parent would be really frustrated if they suffered a burglary simply because someone left their door unlocked, the system administrator would also be frustrated (at best!). In the case of system administrators, they could lose their jobs if they had spent tons of cash creating the perfect security for a system, and then the system was cracked.

Passwords should be easy to remember and difficult or impossible for others to guess. Best practices dictate that a password should be relatively long (at least six characters, preferably longer), contain a mixture of letters, numbers, and non-alphanumeric characters, be difficult or impossible to guess, and be only associated with one userID on one system at any given time. Moreover, it should be changed frequently. Unfortunately, end users (being human) have difficulty remembering a large number of different random-looking passwords.

What ends up happening is that end users keep "cheat sheets" to help them remember their passwords. In short, they write them down, creating the opportunity for others to find them either accidentally or on purpose. Once a user's password has been compromised, anyone who knows that user's password can log in to the system as that user. After logging in to a system, a cracker can use numerous tools to elevate his or her privileges, and to extract useful information from the system. What's worse is the phenomenon of password re-use, in which an end user simplifies his or her life by using as few as one password on many systems. If a cracker manages to find that password, he or she doesn't have to work as hard.

Some end users are conscientious, and they do use different passwords on different systems. However, there are very few users that don't need to keep some form of record of which passwords are valid on which systems, especially since passwords typically have a fixed lifetime after which they are no longer valid. Moreover, some users have so many accounts on so many different systems that even the most security-conscious end user can be overwhelmed. It is not unheard of for people to keep an electronic file on one of their computers that lists all their userIDs and passwords. If an attacker manages to get this file, his or her workload is greatly reduced.

Even without finding a user's cheat sheet, it is usually not difficult to guess someone's password. If you know anything about a person, you can make a few guesses and have a reasonable chance of successfully logging in. Names of their children, spouse, their own name (perhaps written backwards), important birthdays, anniversaries, and other easily guessable personal data are typically chosen as passwords. The password "password" is seen far too frequently, and this sort of thing gives system administrators heartburn.

Imagine how frustrating this must be to IT managers no matter how strongly they protect the payroll system (or any other business-critical system), it is vulnerable to malicious use if any of its users keep their system password on their computer in written or electronic form. If someone (an attacker) can manage to break in to an end-user's desktop machine, the payroll system has been compromised. Keep in mind that over two-thirds^[12] of all corporate "cracking^[13] " incidents are launched from the inside. It is possible (even likely) that the security protecting the desktop machine is also password-based, and so breaking in to a very secure system on which a user has an account might only be as difficult as breaking in to the user's desktop PC.

^[12] Some studies have reported a higher fraction than this, so consider two-thirds to be the lower bound.

^[13] Such incidents are frequently also referred to as "hacking," but the hacker community (in this case, top-notch programmers) prefers not to be associated with people who deliberately try to gain unauthorized access to systems that they do not own.

How Can a User Create a Good Password?

One technique that the author has found useful is to use a telephone keypad as a number/letter substitution device. It is a convenient one-way function that everyone has access to. For example, if an end-user's prototype password is "lucky day," it can be obfuscated by converting the "y" characters to the number 9 (based on the telephone keypad). The letter "l" can be converted to the number 1 due to the resemblance, and the letter "a" can be replaced by the "@" symbol (over time, a user can build up a private list of transformations that make sense; some people convert the letter "o" into the number zero and the letter "l" into the number 1). The resulting password is "1uck9 d@9", which is relatively easy to derive from the phrase that the user can hopefully remember.

End users can even look at a number on the telephone keypad corresponding to the letter in the password that they are trying to obscure and replace the original letter with another one of the letters that are associated with that number on the telephone keypad. In the past, the author has had several passwords that were purely numeric, which were memorable words that had been converted to numbers, again using the mapping on the telephone keypad. For example, under such a transformation, the string

 "Rumplestiltskin" 

becomes

 "786753784587546". 

If the l-to-1 substitution had been made, then the resulting string would have been:

 "786713784187546". 

An end user would probably not choose a password that long, because it might be difficult to remember such a long string of numbers, but having a private set of transforms that can be applied to a set of easily remembered words (or phrases^[14]) might make it possible for the user to remember password(s) without needing to write them down even if the user has to change passwords fairly frequently (some particularly draconian^[15] system administrators may limit passwords to a lifetime of 60 days…or less!).

^[14] One technique is to take a favorite quote, such as the line from the Blues Brothers movie "We're on a mission from God," and abbreviate it down to the initial letters; in other words, "woamfg." Then, one can do some other substitutions; for example, change the letter "o" to a zero, and add some punctuation marks, which might produce the following: "*w0amfg!" As this example has shown, the use of phrases in passwords need not be limited to writing them out word for word.

^[15] Draconian is perhaps a bit harsh. Security conscious may be a better term. However, in their well-intentioned effort to make sure that passwords are fresh, they drive some users toward bad habits.

DILBERT reprinted by permission of United Feature Syndicate, Inc.

The way to make the system administrator happy, and keep end users from unwittingly enabling an otherwise secure system to be compromised and misused, is for end users to have some sort of personal system of transforms that they can use to help them derive all their passwords on-the-fly, without needing to have them written down on a cheat sheet.

No matter how fancy the authentication or encryption algorithms protecting a secured system are, if an attacker can obtain a valid userID and password, he or she can log in to a system and do whatever that user is allowed to do, and in addition could use that access to install software to, for example, elevate his or her status from "end user" to "system administrator," and then wreak all kinds of havoc. The attacker could also install "sniffer" software that would capture all the logins and store the userIDs and their associated passwords in a well-hidden file for later retrieval by the attacker. All the attacker has to do to retrieve the file is to log in again (it's a reasonable assumption that the user will not have changed his or her password in the interim).

The weakness of passwords is legendary in security circles. In truth, any password-based scheme has its limitations. There exist "one-time password" algorithms that can generate a password that is only used once, which removes one of the biggest weaknesses in password-based systems; namely, that people never change them. Even with the best passwords, that consist of random-looking alphanumeric strings, and that are relatively long (10 or more characters), it is still possible to apply the password insecurely. In the WEP scheme that was part of IEEE 802.11-1999, the entire WLAN shares the same key(s). These keys are either 40-bit numbers, or in later products, 104-bit numbers. However, all the STAs must know the keys, and they are effectively static.

This creates problems, since any employees who leave the company can take their knowledge of the keys with them. Since WEP-based WLAN access control amounts to proving that you know the keys, it would be possible for the ex-employees (or anyone that they shared the keys with) to sit in the parking lot and access the WLAN, simply by entering those keys in their wireless STA. Newer WLAN security schemes rely on strong mutual authentication between the STA and the wireless infrastructure, which binds a randomly chosen session key to each individual association. The keys are never re-used, so there is no chance of someone walking away with the key(s). In addition, since the newer schemes are based on user-oriented credentials, it is easy to invalidate those credentials so that the user can not attach to the network again.

Security Is Hard Network Security or Otherwise

Anecdotally, in the 1960s and 1970s, it became fashionable for wealthy homeowners near Los Angeles to install security systems on the windows and doors of their homes. At first, the burglars simply avoided those houses that had security systems, in favor of ones that had not yet been protected. However, eventually the proportion of houses with security systems got high enough that the burglars were forced to adopt a new approach. They knew that they would not be successful if they tried to enter through a door or window. They also knew that most of these houses were quite isolated from each other. Once they were sure that no one was at home, they simply showed up with a chainsaw and made their own entrance right through a wall, without setting off the security system.

In general, an attacker will tend toward exploiting the weakest part of a system, similar to the way that electricity always follows the path of least resistance. One difficulty with designing secure systems is imagining where all the weaknesses might be. This difficulty applies whether or not we are talking about network security. The best-intentioned system designer might create a set of pieces that, when put together in just the right way, is quite secure. However, the designer is not involved in deploying his or her product, and it is all too easy to compromise a system by cutting a seemingly innocuous corner in the deployment phase. It is too easy to focus on the security aspects individually, and ignore their interaction with the rest of the system. The homeowners who had their walls breached never considered that form of attack in their security design, but by making it much harder to breach the windows and doors, their security system inadvertently made the walls an easier target.

Eventually, the homeowners countered with more advanced security systems that included motion detectors and infrared sensors, which made the system so difficult to bypass that the only reasonable way in became finding out how to turn the system off. There are a number of surprisingly easy ways to obtain this information. A thief could make a phone call and claim to be a representative of the security system vendor doing some sort of remote test (for which the pass code is allegedly needed). The thief could try to bribe the house staff. The thief could even dress up as a repair person and bribe a child who lives in the house. A candy bar might suffice to get the desired information. These types of attacks are known as "social engineering" in the cracker world.

The prospective thief could also simply cut the communications link that the home security system uses to alert the security service's command center when it detects a break-in. If the alarm is going off, but no one knows, the attacker is free to take whatever he or she wants. (To prevent this type of attack, the command center probably should poll every one of its client residences on a fairly regular basis; e.g., once every 90 150 seconds. If the system does not respond, an alarm could be triggered.)

The point of this discussion is that no matter how advanced a system's security is, the easiest strategy for an attacker is to find a way to bypass or nullify the security system entirely, perhaps by finding a way to disable it, or by finding a way to get inside the system in a way that the system believes to be legitimate. In network security, attackers rarely if ever try to break encryption algorithms; they try to find a way to obtain legitimate keys, so they can impersonate a real user.

Complexity is the enemy of security. A quote from C. A. R. Hoare on software design in general applies equally well to security design and deployment:

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

The first method is far more difficult."

Sir Charles Antony Richard Hoare

Summary of Motivations for WLAN Security

Given that the WM intrinsically enables eavesdropping, there is a natural tendency to want to do something to protect traffic between the STA and AP so it is at least as confidential as a wired connection to a switch. The only way to accomplish this is to cryptographically manipulate the data such that no other STA can decode the frame (the AP must be able to decrypt traffic from all the STAs^[16] ).

^[16] The requirement that the AP be able to accept encrypted traffic from each STA implies (at least) pairwise keys. Another arrangement that enables the AP to understand data from each STA is to have all the STAs share the same keying material; however, whenever the keying material is known more widely than necessary, there is increased risk that the keys will be exposed to parties that should not be aware of them.

Given that designers of WLAN protocols and products know that eavesdropping is possible, we must expect that eavesdroppers are present and behave accordingly. This may sound paranoid, but most people would probably say that at least some of their data is valuable enough that it is worth taking steps to protect against casual eavesdropping.

I have personally had the experience that my opportunistic downstairs neighbor associated with my AP and was using it as a source of free Internet access. I do not personally have a problem with people setting up mini-ISPs and sharing the cost of a common Internet link among their friends.^[17] I do have a problem with someone taking service from me without asking. Therefore, I cut them off by configuring my AP to ignore frames sent from their MAC address. I don't personally have anything on my computers that anyone else would find interesting, but I pay money each month for broadband Internet access, and I'm not a nonprofit mini-ISP.

^[17] The main reason why the author does not have a problem with this is that from the ISP's perspective, their exposure is limited to whatever can fit through just the one link, which is only capable of pulling down content up to the speed of the link, regardless of how many computers are attached to the link. Sure, the ISP would love it if each of those computers had its own access line, or at least was paying a marginal fee, but that's not economically feasible for many people.

There have been numerous stories in the press about people driving to parking lots near businesses and using a WLAN card to access the Internet, and even in some cases the corporate network. In one case, a researcher was able to detect wireless LANs from 300 500 meters overhead while flying in a small plane (as Dave Barry would say, I am not making this up). Such stories have made it clear that existing wireless LAN deployments are not secure, especially if they do not take measures to protect against unauthorized access. To a certain extent, these stories have probably hindered the growth of the WLAN market, since many companies have almost certainly avoided investing in this technology until the security issues are resolved, or at least substantially improved.

These improvements are, in reality, imminent. The IEEE 802.11 WG created Task Group "i" (also known as IEEE 802.11 TGi, IEEE 802.11i, or simply "TGi"), with the objective of enhancing WLAN security beyond what was available in the most recent version of IEEE 802.11, namely IEEE 802.11-1999. On a related front, the Wi-Fi Alliance, in a quasi-standard, has endorsed part of the emerging IEEE 802.11i work-in-progress and refers to it as Wi-Fi Protected Access (WPA). WPA extracts the parts of IEEE 802.11i that are the most stable; however, due to considerations to be discussed later in the chapter, it is unfortunately not the most secure piece.

However, that compromise represents a tradeoff between enabling vendors to offer significantly improved (but admittedly imperfect) security that could be installed as a firmware upgrade on older hardware, vs. much better security that would require a "forklift upgrade" (i.e., deployment of new hardware). Despite the fact that it is not perfect, WPA is a real improvement over WEP, the security standard that has been part of IEEE 802.11 since IEEE 802.11-1997. WEP and other security protocols pertinent to WLANs will be described in the remainder of this chapter.