WPA/RSN Information Element
The messages that pass capabilities information include capability bits and Information Elements, as described in Chapter 5. RSN/WPA systems
have a specific Information Element that is used to negotiate the type of
security that will be used. This works as follows. If an access point supports
either RSN or WPA (or both), it includes in its beacon and probe response an
Information Element with the following information:
-
Whether the access point is using preshared key or
authentication server (key management)
-
What group security mechanism is operating
-
A list of one or more pairwise key security mechanisms that are
supported
For example, a company that is transitioning from WEP to WPA
might use WEP for broadcast (group) security and allow either WEP or TKIP on a
device-by-device basis. The Information Element would inform WPA devices and
they would select to use WEP/TKIP. The older WEP stations would not understand
the new Information Element and would continue to use WEP/WEP, which is
acceptable in this case. Later, the company might discontinue the use of WEP and
the Information Element would indicate TKIP for broadcasts and only TKIP for
pairwise connections.
If that same company then migrated to RSN, it might start
advertising TKIP for broadcast and a choice of AES or TKIP for pairwise
connections. The Information Element for RSN is not quite the same as for WPA
and may contain more information. RSN is indicated by a capability bit and, if
this bit is set, the default is to use AES–CCMP for both group and pairwise
connections. The Information Element would be needed only if, as in the example
above, a choice was offered.
The Information Element (IE) described so far is sent by the
access point in beacons and probe responses. The mobile device must also include
an Information Element in its association request if it wants to use the
security capabilities. Although the IE sent by the access point might have a
list of protocols to choose, the one sent with the association request must
indicate only a single choice. This is the selection made by the mobile device
and defines the protocol that will be used from that point on.
Validating the Information Elements
If the access point advertises a choice of TKIP or WEP, the
mobile device may legitimately select to use WEP. This would be pretty strange,
though. If the mobile device understands the Information Element, it must
support WPA or RSN, so why would it choose an inferior security system like WEP?
The simple answer is that it would not—unless there had been foul play. This
example leads us to a potential weakness that must be prevented.
Suppose an attacker watches an access point and makes a note of
what information is sent in probe responses. Remember that these messages are
not encrypted; they are open for all to see. Suppose the access point is
offering both TKIP and WEP. Now a new mobile device arrives and issues a probe
request. The access point responds, but the attacker goes into action and blocks
the response by transmitting some well-timed garbage. The attacker now forges a
message that looks exactly like the valid response except that it offers only WEP as a choice. The mobile device thinks the access point
only supports WEP and associates with this choice. The access point might think
this is strange, but it appears quite valid. What the attacker has achieved is
to force the mobile device to use a weaker security method; he has successfully
weakened the target system.
To prevent this type of attack, both the access point and the
mobile device send another copy of the valid Information Element during the
pairwise four-way handshake. The four-way handshake is protected against any
sort of tampering so, although the attacker can substitute the modified
Information Element in the original response, he can't substitute it in the
four-way handshake. Therefore, by keeping a copy of the original message, both
the mobile device and the access point can detect the attack and drop the
connection.
In this example, protection of the Information Element sent by
the mobile device seems less important. Suppose the mobile device selects TKIP
and indicates this in its association request. There wouldn't be much point in
an attacker changing the selection to WEP because, even if accepted by the
access point, not much will happen when the mobile device sends TKIP-encrypted
frames to an access point that is expecting WEP! However, there is another
reason for protecting the mobile device's selection. This is a more subtle
reason and is associated with the process of preauthentication described in the
next section.
Sections
Archive
Syndication
