Patent Application
20060114863
The present invention relates generally to wireless communications and more specifically to techniques for protecting wireless networks.
The Institute of Electrical and Electronic Engineers (IEEE) 802.11 standard supplemented with the 802.11i extensions defines a way for authenticating users for admission into a wireless network and encrypting their traffic for confidentiality.
A weakness of the 802.11i standard is that it does not prevent a wireless “attacker” node from “spoofing” the Media Access Control (MAC) address, e.g., the Ethernet or 802.11 address of another node, because the 802.11i standard does not bind a user identity to a MAC address. When such an attacker spoofs the MAC address of another (second) node, then the network infrastructure may redirect frames intended for the second node to the attacker. The parent access point (AP) will transmit the redirected packets encrypted with the attacker's encryption key, preventing the node that should be receiving the packet from receiving them.
For example, consider the following scenario. An attacker node, A, snoops frames transmitted or received by another wireless client, e.g., B, and learns B's MAC address. This is easy to do as the MAC header of 802.11 frames are transmitted unencrypted over the air. Attacker node A can now associate with a wireless access point using B's MAC address. Once A associates with a wireless access point, traffic intended for B will now be directed to A, secured by a key allocated to A and decipherable by A. Other, more complex, attacks are also possible.
Generally, such attacks are limited to attackers that are on the same subnet. However, some wireless local area network (WLAN) solutions forward packets across subnet boundaries to provide seamless mobility to WLAN users. Unfortunately, such WLAN solutions are vulnerable to MAC address spoofing attacks where an attacker may spoof the address of a legitimate user on a different subnet, so that traffic intended for the legitimate user is redirected to the attacker across subnet boundaries.
In accordance with an aspect of the present invention, the present invention contemplates an authenticating entity that will verify the MAC address and user identity bindings of an incoming authentication request against existing MAC address and user identity bindings stored in a “bindings database.” If a new request has an existing MAC address, but not the corresponding user identity, then the request will be denied.
The bindings database contains the MAC Address, User identity bindings for wireless nodes and/or, for wired nodes. The MAC address, User identity bindings contained in the bindings database may be automatically learned or statically configured.
Still other objects of the present invention will become readily apparent to those skilled in this art from the following description wherein there is shown and described a preferred embodiment of this invention, simply by way of illustration of one of the best modes best suited for to carry out the invention. As it will be realized, the invention is capable of other different embodiments and its several details are capable of modifications in various obvious aspects all without from the invention. Accordingly, the drawing and descriptions will be regarded as illustrative in nature and not as restrictive.
The accompanying drawings incorporated in and forming a part of the specification, illustrates several aspects of the present invention, and together with the description serve to explain the principles of the invention.
Throughout this description, the preferred embodiment and examples shown should be considered as exemplars, rather than limitations, of the present invention. The present invention resolves a security hole in the 802.11 wireless suites, where an attacker spoofs the MAC address of another wired or wireless user. The present invention compares new MAC address and User identity bindings against an existing database of bindings.
An authentication entity connected to the network being protected performs the methodology 100. The authentication entity can be any component on the network, e.g., a separate server, contained within an authentication server such as a RADIUS server, or contained within any access point or other network component can be configured to perform the functionality of the authentication entity as described herein.
At 102, a request for access to a network is received. The request is received from a wireless client. The request comprises a MAC address of the wireless client. However, in alternative embodiments of the present invention, wired components, such as new access points being connected to a network, attempting to access the network would also supply their MAC addresses.
At 104, a user identity corresponding to the MAC address received at 102 is received. In one embodiment, the user identity is received in the same message as the request with the MAC address. In an alternative embodiment, the user identity is sent in a separate message. For example, the current Institute of Electrical and Electronic Engineers (IEEE) 802.11i standard requires each authenticated user to send an Extensible Authentication Protocol (EAP) Identity message to an 802.1X authenticator within the network intrastructure. In one embodiment of the present invention, the user identity (UserID), which is bound to a MAC address is obtained from an EAP Identity message (e.g., the EAPID field) sent by the user.
An alternative method for obtaining the user ID is available for cases where a session key is used by the central authentication server (e.g., the AAA server) the first time the node authenticates. The authenticator (e.g., WDS) may cache this session key and establish a binding between the user ID (as learned from the EAP-ID) and this session key. When the node roams and reassociates with a new AP, it may not undergo the same sequence of authentication as before. In particular, the node may not furnish a user ID as an EAP-ID attribute. Instead, its reassociation message exchanged will furnish a checksum value (called MIC) that indirectly proves knowledge of the previously established session key without actually producing that session key (for privacy reasons). The authenticator (e.g., the WDS) will then use the indication of this knowledge of the session key by the wireless node and retrieve the user ID previously bound to this session key.
At 106, a database is searched for the MAC address. At 108, it is determined whether the MAC address was found in the database. If the MAC address does not already have an associated user identity (NO), then at 110 the database is updated. The database is updated by storing the association of the MAC address obtained at 102 with the user identity obtained at 104. Thus, subsequent requests for access to the network (such as an association request at another access point) will check that the user identity and MAC address match the user identity and MAC address stored at 110.
If, at 108, the MAC address is found in the database (YES), then at 112 the user identity received at 104 is compared with the user identity stored in the database. If at 112, the user identity received at 104 matches the user identity stored in the database for the MAC address received at 102, then at 114 the request is allowed. However, if at 112, it is determined that the user identity received at 104 does not match the user identity stored in the database for the MAC address received at 102 (NO), then at 116 access is denied, thus preventing a spoofed MAC address attack.
Alternative embodiments contemplate that in addition to or in lieu of denying access at 116 other actions may be taken in response to the detection of a spoofed MAC address attack. For example, instances of spoofed MAC address can be logged to as an exception at either a local and/or local server. Other alternative embodiments contemplate one or more generating SNMP traps, printing alert messages on a console (not shown), sending notifications, or other types of alarms can be generated.
Once a client (e.g. a wireless client or a wired component such as an access point) is stored in the database, when a subsequent request to access the network is received that has the client's MAC address, the MAC address for the requester can be verified. For example, at 102 the MAC address for the requestor for the subsequent request is obtained. At 104, the user identity for the requester of the subsequent request is obtained. At 106, the database is searched. Because the MAC address for the client is already stored, then at 108 the MAC address is found. At 112, the user identity for the subsequent request is compared to the user identity stored with the MAC address in the database. If at 112, the user identity for the subsequent request matches the user identity associated with the MAC address obtained at 102 (YES) then at 114 access is allowed, otherwise (NO) at 116, access is denied.
When a user logs out of the network, the database is updated and the user identity associated with the MAC address is either cleared, or the record is removed from the database. Thus, if another user begins to use the client, because the MAC address no long has an associated user name, the new user can log into the network. The authentication entity being responsive to a new user being associated with the MAC address, would update the database with the new user identity associated with the MAC address. Until the new user logs out, any attempt to access the network using the same MAC address without the correct user identity would be prevented by the authentication entity.
Alternatively, the authentication entity can remove the association of the MAC address with the user identity after a predetermined time occurs and no activity has been received by the user. This will allow the system to automatically log out a user identity when a device is powered off without logging out. Ordinarily, when no traffic has been received from a device for a few seconds (or as little as one) it is assumed that the device has been turned off.
When a client, such as client 212, wants to access network 200, it sends a wireless communication to at an access point (AP), such as access point 210 (as shown) or 208. The access point 210 is suitably adapted to determine the wireless client's 202 MAC address. Additionally, the access point 210 determines the wireless client's 202 user identity. AP 210 sends a message to the authentication entity 202 via network backbone 206 to ascertain whether the user identity matches the MAC address supplied by the client. The user identity can be obtained via an EAPID field of an EAP request. Alternatively, the user identity can be inferred from a MIC associated with the request.
Authentication entity 202 inquires database 204 for the MAC address. If the MAC address is not found, then a new entry is inserted into the database. Thus, when a subsequent request is received using the same MAC address, database 204 uses the entry to validate the request.
In an alternative embodiment, database 204 is configured to be static. When database 204 is configured to be static, then if the MAC address for client 212 is not found, it is denied access to the network. An example of this embodiment is illustrated in
As shown, an intruder 214, while at position 216 overhears the client 212 communicating with AP 210. Because the MAC address for client 212 is sent unencrypted, intruder 214 is able to obtain the MAC address for client 212. Intruder 214 then communications with AP 208, requesting access to network 200 using the MAC address of client 212. AP 208 obtains a user identity for intruder 214. AP 208 then contacts authentication entity 202 via network backbone 206. When the authentication entity 202 compares the MAC address and user identity obtained sent by intruder 214 with the stored MAC address and user identity for client 212, authentication entity 202 determines that intruder 214 is using a spoofed MAC address. Authentication entity 202 then prevents intruder 214 from accessing the network by communicating to AP 208 that intruder 214 is not authorized to access the network.
In accordance with another aspect of the present invention, the present invention is useful to protect the network 100 infrastructure from rogue components accessing the network. For example, by configuring database 204 with a list of valid network components, for example access points, when a new access point 212 attempts to access the network 200 via network backbone 206, authentication entity ascertains the MAC address and if database 204 has been configured accordingly, the user identity for AP 212.
if AP 212 does not send the correct MAC address and/or user identity, then authentication entity prevents AP 212 from communicating with the rest of the network, for example by not distributing key pairs.
In accord with an aspect, the present invention is related to the use of computer system 300 for protecting a network against MAC address spoofing. According to one embodiment of the invention, protection against MAC address spoofing is provided by computer system 300 in response to processor 304 executing one or more sequences of one or more instructions contained in main memory 306. Such instructions may be read into main memory 306 from another computer-readable medium, such as storage device 310. Execution of the sequence of instructions contained in main memory 306 causes processor 304 to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in main memory 306. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor 304 for execution. Such a medium may take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Non-volatile media include for example optical or magnetic disks, such as storage device 310. Volatile media include dynamic memory such as main memory 306. Transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise bus 302. Transmission media can also take the form of acoustic or light waves such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include for example floppy disk, a flexible disk, hard disk, magnetic cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASHPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to processor 304 for execution. For example, the instructions may initially be borne on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 300 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector coupled to bus 302 can receive the data carried in the infrared signal and place the data on bus 302. Bus 302 carries the data to main memory 306 from which processor 304 retrieves and executes the instructions. The instructions received by main memory 306 may optionally be stored on storage device 310 either before or after execution by processor 104.
Computer system 300 also includes a communication interface 318 coupled to bus 302. Communication interface 318 provides a two-way data communication coupling to a network link 320 that is connected to a local network, such as for example network backbone 206 in
Network link 320 typically provides data communication through one or more networks to other devices on the network. For example, network link 320 may provide a connection to AP 208 and/or AP 210 (
Furthermore, instruction code for processor 304 can be received from network link 320 using communication interface 318. The received code may be executed by processor 304 as it is received, and/or stored in storage device 310, or other non-volatile storage for later execution. In this manner, computer system 300 may obtain application code in the form of a carrier wave.
At 402, a request for access to a network is received. The request is received from a wireless client. The request comprises a MAC address of the wireless client. However, in alternative embodiments of the present invention, wired components, such as new access points being connected to a network, attempting to access the network would also supply their MAC addresses.
At 404, a user identity corresponding to the MAC address received at 402 is received. In one embodiment, the user identity is received in the same message as the request with the MAC address. In an alternative embodiment, the user identity is sent in a separate message, such as for example the EAPID field of an EAP message. Alternatively, for cases where a session key is used by the central authentication server (e.g., the AAA server) the first time the node authenticates the authenticator (e.g., WDS) may cache this session key and establish a binding between the user ID (as learned from the EAP-ID) and this session key. When the node roams and reassociates with a new AP, it may not undergo the same sequence of authentication as before. In particular, the node may not furnish a user ID as an EAP-ID attribute. Instead, its reassociation message exchanged will furnish a checksum value (called MIC) that indirectly proves knowledge of the previously established session key without actually producing that session key (for privacy reasons). The authenticator (e.g., the WDS) will then use the indication of this knowledge of the session key by the wireless node and retrieve the user ID previously bound to this session key.
At 406, a database is searched for the MAC address. At 408, it is determined whether the MAC address was found in the database. If the MAC address is not in the database (NO), then at 410 access to the network is denied. If, at 408, the MAC address is found in the database (YES), then at 412 the user identity received at 404 is compared with the user identity stored in the database. If at 412, the user identity received at 404 matches the user identity stored in the database for the MAC address received at 402, then at 414 the request is allowed. However, if at 412, it is determined that the user identity received at 404 does not match the user identity stored in the database for the MAC address received at 402 (NO), then at 416 access is denied, thus preventing a spoofed MAC address attack.
What has been described above includes exemplary implementations of the present invention. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the present invention, but one of ordinary skill in the art will recognize that many further combinations and permutations of the present invention are possible. Accordingly, the present invention is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims interpreted in accordance with the breadth to which they are fairly, legally and equitably entitled.
