mirror of
https://github.com/vanhoefm/fragattacks.git
synced 2024-11-26 17:28:29 -05:00
50b5bf4eda
The Prism54.org project seems have been dead for a while and it does not look like this driver would ever be maintained again. Furthermore, it is difficult to find a version that would work with the driver_prism54.c wrapper and there is another driver for these card in the Linux kernel tree. The hostapd integration in driver_prism54.c is quite different from the other driver wrappers and would require major effort to get it cleaned up. Since there does not seem to be any real users for the cleaned up version, there does not seem to be justification to spend this effort on the wrapper. This old code is making it much more difficult to clean up the driver interface and at this point, the best option seems to be to remove the driver wrappers. Should someone really still need this, the old code will continue to be available in hostapd 0.6.x.
388 lines
17 KiB
Plaintext
388 lines
17 KiB
Plaintext
hostapd - user space IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP
|
|
Authenticator and RADIUS authentication server
|
|
================================================================
|
|
|
|
Copyright (c) 2002-2009, Jouni Malinen <j@w1.fi> and contributors
|
|
All Rights Reserved.
|
|
|
|
This program is dual-licensed under both the GPL version 2 and BSD
|
|
license. Either license may be used at your option.
|
|
|
|
|
|
|
|
License
|
|
-------
|
|
|
|
GPL v2:
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
it under the terms of the GNU General Public License version 2 as
|
|
published by the Free Software Foundation.
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
GNU General Public License for more details.
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
along with this program; if not, write to the Free Software
|
|
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
|
|
|
(this copy of the license is in COPYING file)
|
|
|
|
|
|
Alternatively, this software may be distributed, used, and modified
|
|
under the terms of BSD license:
|
|
|
|
Redistribution and use in source and binary forms, with or without
|
|
modification, are permitted provided that the following conditions are
|
|
met:
|
|
|
|
1. Redistributions of source code must retain the above copyright
|
|
notice, this list of conditions and the following disclaimer.
|
|
|
|
2. Redistributions in binary form must reproduce the above copyright
|
|
notice, this list of conditions and the following disclaimer in the
|
|
documentation and/or other materials provided with the distribution.
|
|
|
|
3. Neither the name(s) of the above-listed copyright holder(s) nor the
|
|
names of its contributors may be used to endorse or promote products
|
|
derived from this software without specific prior written permission.
|
|
|
|
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
|
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
|
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
|
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
|
|
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
|
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
|
|
|
|
Introduction
|
|
============
|
|
|
|
Originally, hostapd was an optional user space component for Host AP
|
|
driver. It adds more features to the basic IEEE 802.11 management
|
|
included in the kernel driver: using external RADIUS authentication
|
|
server for MAC address based access control, IEEE 802.1X Authenticator
|
|
and dynamic WEP keying, RADIUS accounting, WPA/WPA2 (IEEE 802.11i/RSN)
|
|
Authenticator and dynamic TKIP/CCMP keying.
|
|
|
|
The current version includes support for other drivers, an integrated
|
|
EAP server (i.e., allow full authentication without requiring
|
|
an external RADIUS authentication server), and RADIUS authentication
|
|
server for EAP authentication.
|
|
|
|
|
|
Requirements
|
|
------------
|
|
|
|
Current hardware/software requirements:
|
|
- drivers:
|
|
Host AP driver for Prism2/2.5/3.
|
|
(http://hostap.epitest.fi/)
|
|
Please note that station firmware version needs to be 1.7.0 or newer
|
|
to work in WPA mode.
|
|
|
|
madwifi driver for cards based on Atheros chip set (ar521x)
|
|
(http://sourceforge.net/projects/madwifi/)
|
|
Please note that you will need to add the correct path for
|
|
madwifi driver root directory in .config (see defconfig file for
|
|
an example: CFLAGS += -I<path>)
|
|
|
|
mac80211-based drivers that support AP mode (with driver=nl80211).
|
|
This includes drivers for Atheros (ath9k) and Broadcom (b43)
|
|
chipsets.
|
|
|
|
Any wired Ethernet driver for wired IEEE 802.1X authentication
|
|
(experimental code)
|
|
|
|
FreeBSD -current (with some kernel mods that have not yet been
|
|
committed when hostapd v0.3.0 was released)
|
|
BSD net80211 layer (e.g., Atheros driver)
|
|
|
|
|
|
Build configuration
|
|
-------------------
|
|
|
|
In order to be able to build hostapd, you will need to create a build
|
|
time configuration file, .config that selects which optional
|
|
components are included. See defconfig file for example configuration
|
|
and list of available options.
|
|
|
|
|
|
|
|
IEEE 802.1X
|
|
===========
|
|
|
|
IEEE Std 802.1X-2001 is a standard for port-based network access
|
|
control. In case of IEEE 802.11 networks, a "virtual port" is used
|
|
between each associated station and the AP. IEEE 802.11 specifies
|
|
minimal authentication mechanism for stations, whereas IEEE 802.1X
|
|
introduces a extensible mechanism for authenticating and authorizing
|
|
users.
|
|
|
|
IEEE 802.1X uses elements called Supplicant, Authenticator, Port
|
|
Access Entity, and Authentication Server. Supplicant is a component in
|
|
a station and it performs the authentication with the Authentication
|
|
Server. An access point includes an Authenticator that relays the packets
|
|
between a Supplicant and an Authentication Server. In addition, it has a
|
|
Port Access Entity (PAE) with Authenticator functionality for
|
|
controlling the virtual port authorization, i.e., whether to accept
|
|
packets from or to the station.
|
|
|
|
IEEE 802.1X uses Extensible Authentication Protocol (EAP). The frames
|
|
between a Supplicant and an Authenticator are sent using EAP over LAN
|
|
(EAPOL) and the Authenticator relays these frames to the Authentication
|
|
Server (and similarly, relays the messages from the Authentication
|
|
Server to the Supplicant). The Authentication Server can be colocated with the
|
|
Authenticator, in which case there is no need for additional protocol
|
|
for EAP frame transmission. However, a more common configuration is to
|
|
use an external Authentication Server and encapsulate EAP frame in the
|
|
frames used by that server. RADIUS is suitable for this, but IEEE
|
|
802.1X would also allow other mechanisms.
|
|
|
|
Host AP driver includes PAE functionality in the kernel driver. It
|
|
is a relatively simple mechanism for denying normal frames going to
|
|
or coming from an unauthorized port. PAE allows IEEE 802.1X related
|
|
frames to be passed between the Supplicant and the Authenticator even
|
|
on an unauthorized port.
|
|
|
|
User space daemon, hostapd, includes Authenticator functionality. It
|
|
receives 802.1X (EAPOL) frames from the Supplicant using the wlan#ap
|
|
device that is also used with IEEE 802.11 management frames. The
|
|
frames to the Supplicant are sent using the same device.
|
|
|
|
The normal configuration of the Authenticator would use an external
|
|
Authentication Server. hostapd supports RADIUS encapsulation of EAP
|
|
packets, so the Authentication Server should be a RADIUS server, like
|
|
FreeRADIUS (http://www.freeradius.org/). The Authenticator in hostapd
|
|
relays the frames between the Supplicant and the Authentication
|
|
Server. It also controls the PAE functionality in the kernel driver by
|
|
controlling virtual port authorization, i.e., station-AP
|
|
connection, based on the IEEE 802.1X state.
|
|
|
|
When a station would like to use the services of an access point, it
|
|
will first perform IEEE 802.11 authentication. This is normally done
|
|
with open systems authentication, so there is no security. After
|
|
this, IEEE 802.11 association is performed. If IEEE 802.1X is
|
|
configured to be used, the virtual port for the station is set in
|
|
Unauthorized state and only IEEE 802.1X frames are accepted at this
|
|
point. The Authenticator will then ask the Supplicant to authenticate
|
|
with the Authentication Server. After this is completed successfully,
|
|
the virtual port is set to Authorized state and frames from and to the
|
|
station are accepted.
|
|
|
|
Host AP configuration for IEEE 802.1X
|
|
-------------------------------------
|
|
|
|
The user space daemon has its own configuration file that can be used to
|
|
define AP options. Distribution package contains an example
|
|
configuration file (hostapd/hostapd.conf) that can be used as a basis
|
|
for configuration. It includes examples of all supported configuration
|
|
options and short description of each option. hostapd should be started
|
|
with full path to the configuration file as the command line argument,
|
|
e.g., './hostapd /etc/hostapd.conf'. If you have more that one wireless
|
|
LAN card, you can use one hostapd process for multiple interfaces by
|
|
giving a list of configuration files (one per interface) in the command
|
|
line.
|
|
|
|
hostapd includes a minimal co-located IEEE 802.1X server which can be
|
|
used to test IEEE 802.1X authentication. However, it should not be
|
|
used in normal use since it does not provide any security. This can be
|
|
configured by setting ieee8021x and minimal_eap options in the
|
|
configuration file.
|
|
|
|
An external Authentication Server (RADIUS) is configured with
|
|
auth_server_{addr,port,shared_secret} options. In addition,
|
|
ieee8021x and own_ip_addr must be set for this mode. With such
|
|
configuration, the co-located Authentication Server is not used and EAP
|
|
frames will be relayed using EAPOL between the Supplicant and the
|
|
Authenticator and RADIUS encapsulation between the Authenticator and
|
|
the Authentication Server. Other than this, the functionality is similar
|
|
to the case with the co-located Authentication Server.
|
|
|
|
Authentication Server and Supplicant
|
|
------------------------------------
|
|
|
|
Any RADIUS server supporting EAP should be usable as an IEEE 802.1X
|
|
Authentication Server with hostapd Authenticator. FreeRADIUS
|
|
(http://www.freeradius.org/) has been successfully tested with hostapd
|
|
Authenticator and both Xsupplicant (http://www.open1x.org) and Windows
|
|
XP Supplicants. EAP/TLS was used with Xsupplicant and
|
|
EAP/MD5-Challenge with Windows XP.
|
|
|
|
http://www.missl.cs.umd.edu/wireless/eaptls/ has useful information
|
|
about using EAP/TLS with FreeRADIUS and Xsupplicant (just replace
|
|
Cisco access point with Host AP driver, hostapd daemon, and a Prism2
|
|
card ;-). http://www.freeradius.org/doc/EAP-MD5.html has information
|
|
about using EAP/MD5 with FreeRADIUS, including instructions for WinXP
|
|
configuration. http://www.denobula.com/EAPTLS.pdf has a HOWTO on
|
|
EAP/TLS use with WinXP Supplicant.
|
|
|
|
Automatic WEP key configuration
|
|
-------------------------------
|
|
|
|
EAP/TLS generates a session key that can be used to send WEP keys from
|
|
an AP to authenticated stations. The Authenticator in hostapd can be
|
|
configured to automatically select a random default/broadcast key
|
|
(shared by all authenticated stations) with wep_key_len_broadcast
|
|
option (5 for 40-bit WEP or 13 for 104-bit WEP). In addition,
|
|
wep_key_len_unicast option can be used to configure individual unicast
|
|
keys for stations. This requires support for individual keys in the
|
|
station driver.
|
|
|
|
WEP keys can be automatically updated by configuring rekeying. This
|
|
will improve security of the network since same WEP key will only be
|
|
used for a limited period of time. wep_rekey_period option sets the
|
|
interval for rekeying in seconds.
|
|
|
|
|
|
WPA/WPA2
|
|
========
|
|
|
|
Features
|
|
--------
|
|
|
|
Supported WPA/IEEE 802.11i features:
|
|
- WPA-PSK ("WPA-Personal")
|
|
- WPA with EAP (e.g., with RADIUS authentication server) ("WPA-Enterprise")
|
|
- key management for CCMP, TKIP, WEP104, WEP40
|
|
- RSN/WPA2 (IEEE 802.11i), including PMKSA caching and pre-authentication
|
|
|
|
WPA
|
|
---
|
|
|
|
The original security mechanism of IEEE 802.11 standard was not
|
|
designed to be strong and has proved to be insufficient for most
|
|
networks that require some kind of security. Task group I (Security)
|
|
of IEEE 802.11 working group (http://www.ieee802.org/11/) has worked
|
|
to address the flaws of the base standard and has in practice
|
|
completed its work in May 2004. The IEEE 802.11i amendment to the IEEE
|
|
802.11 standard was approved in June 2004 and this amendment is likely
|
|
to be published in July 2004.
|
|
|
|
Wi-Fi Alliance (http://www.wi-fi.org/) used a draft version of the
|
|
IEEE 802.11i work (draft 3.0) to define a subset of the security
|
|
enhancements that can be implemented with existing wlan hardware. This
|
|
is called Wi-Fi Protected Access<TM> (WPA). This has now become a
|
|
mandatory component of interoperability testing and certification done
|
|
by Wi-Fi Alliance. Wi-Fi provides information about WPA at its web
|
|
site (http://www.wi-fi.org/OpenSection/protected_access.asp).
|
|
|
|
IEEE 802.11 standard defined wired equivalent privacy (WEP) algorithm
|
|
for protecting wireless networks. WEP uses RC4 with 40-bit keys,
|
|
24-bit initialization vector (IV), and CRC32 to protect against packet
|
|
forgery. All these choices have proven to be insufficient: key space is
|
|
too small against current attacks, RC4 key scheduling is insufficient
|
|
(beginning of the pseudorandom stream should be skipped), IV space is
|
|
too small and IV reuse makes attacks easier, there is no replay
|
|
protection, and non-keyed authentication does not protect against bit
|
|
flipping packet data.
|
|
|
|
WPA is an intermediate solution for the security issues. It uses
|
|
Temporal Key Integrity Protocol (TKIP) to replace WEP. TKIP is a
|
|
compromise on strong security and possibility to use existing
|
|
hardware. It still uses RC4 for the encryption like WEP, but with
|
|
per-packet RC4 keys. In addition, it implements replay protection,
|
|
keyed packet authentication mechanism (Michael MIC).
|
|
|
|
Keys can be managed using two different mechanisms. WPA can either use
|
|
an external authentication server (e.g., RADIUS) and EAP just like
|
|
IEEE 802.1X is using or pre-shared keys without need for additional
|
|
servers. Wi-Fi calls these "WPA-Enterprise" and "WPA-Personal",
|
|
respectively. Both mechanisms will generate a master session key for
|
|
the Authenticator (AP) and Supplicant (client station).
|
|
|
|
WPA implements a new key handshake (4-Way Handshake and Group Key
|
|
Handshake) for generating and exchanging data encryption keys between
|
|
the Authenticator and Supplicant. This handshake is also used to
|
|
verify that both Authenticator and Supplicant know the master session
|
|
key. These handshakes are identical regardless of the selected key
|
|
management mechanism (only the method for generating master session
|
|
key changes).
|
|
|
|
|
|
IEEE 802.11i / WPA2
|
|
-------------------
|
|
|
|
The design for parts of IEEE 802.11i that were not included in WPA has
|
|
finished (May 2004) and this amendment to IEEE 802.11 was approved in
|
|
June 2004. Wi-Fi Alliance is using the final IEEE 802.11i as a new
|
|
version of WPA called WPA2. This includes, e.g., support for more
|
|
robust encryption algorithm (CCMP: AES in Counter mode with CBC-MAC)
|
|
to replace TKIP and optimizations for handoff (reduced number of
|
|
messages in initial key handshake, pre-authentication, and PMKSA caching).
|
|
|
|
Some wireless LAN vendors are already providing support for CCMP in
|
|
their WPA products. There is no "official" interoperability
|
|
certification for CCMP and/or mixed modes using both TKIP and CCMP, so
|
|
some interoperability issues can be expected even though many
|
|
combinations seem to be working with equipment from different vendors.
|
|
Testing for WPA2 is likely to start during the second half of 2004.
|
|
|
|
hostapd configuration for WPA/WPA2
|
|
----------------------------------
|
|
|
|
TODO
|
|
|
|
# Enable WPA. Setting this variable configures the AP to require WPA (either
|
|
# WPA-PSK or WPA-RADIUS/EAP based on other configuration). For WPA-PSK, either
|
|
# wpa_psk or wpa_passphrase must be set and wpa_key_mgmt must include WPA-PSK.
|
|
# For WPA-RADIUS/EAP, ieee8021x must be set (but without dynamic WEP keys),
|
|
# RADIUS authentication server must be configured, and WPA-EAP must be included
|
|
# in wpa_key_mgmt.
|
|
# This field is a bit field that can be used to enable WPA (IEEE 802.11i/D3.0)
|
|
# and/or WPA2 (full IEEE 802.11i/RSN):
|
|
# bit0 = WPA
|
|
# bit1 = IEEE 802.11i/RSN (WPA2)
|
|
#wpa=1
|
|
|
|
# WPA pre-shared keys for WPA-PSK. This can be either entered as a 256-bit
|
|
# secret in hex format (64 hex digits), wpa_psk, or as an ASCII passphrase
|
|
# (8..63 characters) that will be converted to PSK. This conversion uses SSID
|
|
# so the PSK changes when ASCII passphrase is used and the SSID is changed.
|
|
#wpa_psk=0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
|
|
#wpa_passphrase=secret passphrase
|
|
|
|
# Set of accepted key management algorithms (WPA-PSK, WPA-EAP, or both). The
|
|
# entries are separated with a space.
|
|
#wpa_key_mgmt=WPA-PSK WPA-EAP
|
|
|
|
# Set of accepted cipher suites (encryption algorithms) for pairwise keys
|
|
# (unicast packets). This is a space separated list of algorithms:
|
|
# CCMP = AES in Counter mode with CBC-MAC [RFC 3610, IEEE 802.11i]
|
|
# TKIP = Temporal Key Integrity Protocol [IEEE 802.11i]
|
|
# Group cipher suite (encryption algorithm for broadcast and multicast frames)
|
|
# is automatically selected based on this configuration. If only CCMP is
|
|
# allowed as the pairwise cipher, group cipher will also be CCMP. Otherwise,
|
|
# TKIP will be used as the group cipher.
|
|
#wpa_pairwise=TKIP CCMP
|
|
|
|
# Time interval for rekeying GTK (broadcast/multicast encryption keys) in
|
|
# seconds.
|
|
#wpa_group_rekey=600
|
|
|
|
# Time interval for rekeying GMK (master key used internally to generate GTKs
|
|
# (in seconds).
|
|
#wpa_gmk_rekey=86400
|
|
|
|
# Enable IEEE 802.11i/RSN/WPA2 pre-authentication. This is used to speed up
|
|
# roaming be pre-authenticating IEEE 802.1X/EAP part of the full RSN
|
|
# authentication and key handshake before actually associating with a new AP.
|
|
#rsn_preauth=1
|
|
#
|
|
# Space separated list of interfaces from which pre-authentication frames are
|
|
# accepted (e.g., 'eth0' or 'eth0 wlan0wds0'. This list should include all
|
|
# interface that are used for connections to other APs. This could include
|
|
# wired interfaces and WDS links. The normal wireless data interface towards
|
|
# associated stations (e.g., wlan0) should not be added, since
|
|
# pre-authentication is only used with APs other than the currently associated
|
|
# one.
|
|
#rsn_preauth_interfaces=eth0
|