Security Features of 802.11 Wireless LAN

The three basic security services defined by IEEE for the WLAN environment are as follows:

a)  Authentication—A primary goal of WEP was to provide a security service to verify the identity of
communicating client stations. This provides access control to the network by denying access to client
stations that cannot authenticate properly. This service addresses the question, “Are only authorized
persons allowed to gain access to my network?”
b) Confidentiality—Confidentiality, or privacy, was a second goal of WEP. It was developed to provide
“privacy achieved by a wired network.” The intent was to prevent information compromise from
casual eavesdropping (passive attack). This service, in general, addresses the question, “Are only
authorized persons allowed to view my data?”
c)  Integrity—Another goal of WEP was a security service developed to ensure that messages are not
modified in transit between the wireless clients and the access point in an active attack. This service
addresses the question, “Is the data coming into or exiting the network trustworthy—has it been
tampered with?”

It is important to note that the standard did not address other security services such as audit, authorization,
and nonrepudiation. The security services offered by 802.11 are described in greater detail below.

Authentication

The IEEE 802.11 specification defines two means to “validate” wireless users attempting to gain access to
a wired network: open-system authentication and shared-key authentication. One means, shared-key
authentication, is based on cryptography, and the other is not. The open-system authentication technique
is not truly authentication; the access point accepts the mobile station without verifying the identity of the
station. It should be noted also that the authentication is only one-way: only the mobile station is
authenticated. The mobile station must trust that it is communicating to a real AP. A taxonomy of the
techniques for 802.11 is depicted in Figure in below



With Open System authentication, a client is authenticated if it simply responds with a MAC address
during the two-message exchange with an access point. During the exchange, the client is not truly
validated but simply responds with the correct fields in the message exchange. Obviously, with out
cryptographic validatedation, open-system authentication is highly vulnerable to attack and practically
invites unauthorized access. Open-system authentication is the only required form of authentication by the
802.11 specification.
Shared key authentication is a cryptographic technique for authentication. It is a simple “challengeresponse”
scheme based on whether a client has knowledge of a shared secret. In this scheme, as depicted
conceptually in Figure next, a random challenge is generated by the access point and sent to the wireless
client. The client, using a cryptographic key that is shared with the AP, encrypts the challenge (or
“nonce,” as it is called in security vernacular) and returns the result to the AP. The AP decrypts the result
computed by the client and allows access only if the decrypted value is the same as the random challenge
transmitted. The algorithm used in the cryptographic computation and for the generation of the 128-bit
challenge text is the RC4 stream cipher developed by Ron Rivest of MIT. It should be noted that the
authentication method just described is a rudimentary cryptographic technique, and it does not provide
mutual authentication. That is, the client does not authenticate the AP, and therefore there is no assurance
that a client is communicating with a legitimate AP and wireless network. It is also worth noting that
simple unilateral challenge-response schemes have long been known to be weak. They suffer from
numerous attacks including the infamous “man-in-the-middle” attack. Lastly, the IEEE 802.11
specification does not require shared-key authentication.

Privacy

The 802.11 standard supports privacy (confidentiality) through the use of cryptographic techniques for the
wireless interface. The WEP cryptographic technique for confidentiality also uses the RC4 symmetrickey,
stream cipher algorithm to generate a pseudo-random data sequence. This “key stream” is simply
added modulo 2 (exclusive-OR-ed) to the data to be transmitted. Through the WEP technique, data can be
protected from disclosure during transmission over the wireless link. WEP is applied to all data above the
802.11 WLAN layers to protect traffic such as Transmission Control Protocol/Internet Protocol (TCP/IP),
Internet Packet Exchange (IPX), and Hyper Text Transfer Protocol (HTTP).
As defined in the 802.11 standard, WEP supports only a 40-bit cryptographic keys size for the shared key.
However, numerous vendors offer nonstandard extensions of WEP that support key lengths from 40 bits
to 104 bits. At least one vendor supports a keysize of 128 bits. The 104-bit WEP key, for instance, with a
24-bit Initialization Vector (IV) becomes a 128-bit RC4 key. In general, all other things being equal,
increasing the key size increases the security of a cryptographic technique. However, it is always possible
for flawed implementations or flawed designs to prevent long keys from increasing security. Research has
shown that key sizes of greater than 80-bits, for robust designs and implementations, make brute-force
cryptanalysis (code breaking) an impossible task. For 80-bit keys, the number of possible keys—a
keyspace of more than 1026—exceeds contemporary computing power. In practice, most WLAN
deployments rely on 40-bit keys. Moreover, recent attacks have shown that the WEP approach for privacy
is, unfortunately, vulnerable to certain attacks regardless of keysize. However, the cryptographic,
standards, and vendor WLAN communities have developed enhanced WEP, which is available as a
prestandard vendor-specific implementations. The attacks mentioned above are described later in the
following sections.
The WEP privacy is illustrated conceptually in below

Integrity

The IEEE 802.11 specification also outlines a means to provide data integrity for messages transmitted
between wireless clients and access points. This security service was designed to reject any messages that
had been changed by an active adversary “in the middle.” This technique uses a simple encrypted Cyclic
Redundancy Check (CRC) approach. As depicted in the diagram above, a CRC-32, or frame check
sequence, is computed on each payload prior to transmission. The integrity-sealed packet is then
encrypted using the RC4 key stream to provide the cipher-text message. On the receiving end, decryption
is performed and the CRC is recomputed on the message that is received. The CRC computed at the
receiving end is compared with the one computed with the original message. If the CRCs do not equal,
that is, “received in error,” this would indicate an integrity violation (an active message spoofer), and the
packet would be discarded. As with the privacy service, unfortunately, the 802.11 integrity is vulnerable
to certain attacks regardless of key size. In summary, the fundamental flaw in the WEP integrity scheme
is that the simple CRC is not a “cryptographically secure” mechanism such as a hash or message
authentication code.

The IEEE 802.11 specification does not, unfortunately, identify any means for key management (life
cycle handling of cryptographic keys and related material). Therefore, generating, distributing, storing,
loading, escrowing, archiving, auditing, and destroying the material is left to those deploying WLANs.
Key management (probably the most critical aspect of a cryptographic system) for 802.11 is left largely
as an exercise for the users of the 802.11 network. As a result, many vulnerabilities could be introduced
into the WLAN environment. These vulnerabilities include WEP keys that are non-unique, never
changing, factory-defaults, or weak keys (all zeros, all ones, based on easily guessed passwords, or other
similar trivial patterns). Additionally, because key management was not part of the original 802.11
specification, with the key distribution unresolved, WEP-secured WLANs do not scale well. If an
enterprise recognizes the need to change keys often and to make them random, the task is formidable in a
large WLAN environment. For example, a large campus may have as many as 15,000 APs. Generating,
distributing, loading, and managing keys for an environment of this size is a significant challenge. It is
has been suggested that the only practical way to distribute keys in a large dynamic environment is to
publish it. However, a fundamental tenet of cryptography is that cryptographic keys remain secret. Hence
we have a major dichotomy. This dichotomy exists for any technology that neglects to elegantly address
the key distribution problem