This document explains how to set up WPA/WPA2 Enterprise using EAP-TTLS (with PAP) as the authentication mechanism.
Introduction
The original IEEE 802.11 standard defined two basic security mechanisms:
- Open System Authentication, which offers no security at all since any Wireless client can associate with a Wireless Access Point configured in such a way.
Open System Authentication can be useful in public Wireless networks, like those found in airports or public areas. However, this security mechanisms offers no authentication and no confidentiality: data is sent into the air in the clear at the data-link layer, so no encryption and authentication is provided by the upper layers, the transmission can be eavesdropped, hijacked or manipulated.
- Wired Equivalent Privacy, which uses up to four shared-secret keys to “secure” the data transmission at the data-link layer.
One of these four shared-secret keys must be supplied to a Wireless client wanting to associate with the Wireless Access Point. Since there are only four keys available for WEP, some of them will have to be shared among the Wireless clients when the number of Wireless clients exceeds four.
This shared-secret scheme is not scalable, and does not cope well with revocation: trying to revoke access to a Wireless client usually means changing all the WEP keys and redistributing them to the appropriate Wireless clients (since the revoked client is usually a person who still knows some WEP keys and his brain can’t be easily modified to make him forget those WEP keys). Redistributing one or more keys to a large population is infeasible with current key distribution mechanisms, so here is where WPA Enterprise comes into play.
To enhance the security in IEEE 802.11, the IEEE 802.11i has been proposed. In addition to introducing protocols for key management and establishment, it also defines encryption and authentication improvements. In order to manage security keys automatically, the IEEE 802.11i has defined algorithms and protocols for key management and establishment. As conventional WEP is known to be vulnerable, the IEEE 802.11i has specified enhanced encryption algorithms to provide stronger privacy. The IEEE 802.11i also incorporates IEEE 802.1x as its authentication enhancement. The IEEE 802.1x standard is a port-based network access control to authenticate and authorize devices interconnected by various IEEE 802 LANs. The IEEE 802.11i is expected to play a critical role in improving the overall security of current and
future WLANs.
The new security standard, 802.11i, which was ratified in June 2004, fixes all WEP weaknesses. It is divided into three main categories:
- Temporary Key Integrity Protocol (TKIP) is a short-term solution that fixes all WEP weaknesses. TKIP can be used with old 802.11 equipment (after a driver/firmware upgrade) and provides integrity and confidentiality.
- Counter Mode with CBC-MAC Protocol (CCMP) [RFC2610] is a new protocol, designed from ground up. It uses AES [FIPS 197] as its cryptographic algorithm, and, since this is more CPU intensive than RC4 (used in WEP and TKIP), new 802.11 hardware may be required. Some drivers can implement CCMP in software. CCMP provides integrity and confidentiality.
- 802.1X Port-Based Network Access Control, either when using TKIP or CCMP, 802.1X is used for authentication.
In addition, an optional encryption method called “Wireless Robust Authentication Protocol” (WRAP) may be used instead of CCMP. WRAP was the original AES-based proposal for 802.11i, but was replaced by CCMP since it became plagued by property encumbrances. Support for WRAP is optional, but CCMP support is mandatory in 802.11i.
The 802.1X-2001 standard states:
“Port-based network access control makes use of the physical access characteristics of IEEE 802 LAN infrastructures in order to provide a means of authenticating and authorizing devices attached to a LAN port that has point-to-point connection characteristics, and of preventing access to that port in cases which the authentication and authorization fails. A port in this context is a single point of attachment to the LAN infrastructure.” — 802.1X-2001, page 1.
In order to fix the WEP vulnerabilities, the Wi-Fi Alliance took a “snapshot” of the standard (based on draft 3), and called it Wi-Fi Protected Access (WPA). One requirement was that existing 802.11 equipment could be used with WPA, so WPA is basically TKIP + 802.1X.
WPA is not the long term solution. To get a Robust Secure Network (RSN), the hardware must support and use CCMP. RSN is basically CCMP + 802.1X. RSN may also be called WPA2.
If TKIP is used instead of CCMP, it is called Transition Security Network (TSN). TSN is basically TKIP + 802.1X. TSN is also know as WPA.
- TSN = TKIP + 802.1X = WPA
- RSN = CCMP + 802.1X = WPA2
Extensible Authentication Protocol
Extensible Authentication Protocol (EAP) [RFC 3748] is just the transport protocol optimized for authentication, not the authentication method itself:
“[EAP is] an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this.” — RFC 3748, page 3
In 802.1X terminology:
- Supplicant, is a network client asking for authentication in order to access a resource, usually associating with a Wireless Access Point, or requesting access to a wired Ethernet switch.
The Supplicant must supply some form of credentials to an Authentication Server in order to access the requested resource. This credentials can be in the form of user/password combination, a Kerberos ticket, an X.509 client certificate, and so on.
- Authenticator, usually acts as a proxy between the Supplicant and the Authentication Server, although in Wireless networks it is itself the resource being requested by the Supplicant: the Wireless Access Point.
- Authentication Server, is the network component in charge of validating the credentials supplied by the Supplicant.
802.1X uses the Extensible Authentication Protocol (EAP). EAP supports several different authentication mechanisms. Some of them are:
- EAP-MD5: MD5-Challenge requires username/password, and is equivalent to the PPP CHAP protocol [RFC1994].
Requests contain a challenge to the end user. CHAP requires the challenge to be encrypted with a shared secret between the Supplicant and the Authentication Server.
This method does not provide dictionary attack resistance, mutual authentication, or key derivation, and has therefore little use in a wireless authentication enviroment.
EAP-MD5 should not be used alone, but encapsulated inside some other EAP mechanisms, like EAP-TTLS or PEAP.
- Generic Token Card (EAP-GTC): This EAP mechanism allows the exchange of cleartext authentication credentials across the network.
EAP-GTC is usually used as an EAP method to exchange a username and a password, like in PAP (Password Authentication Protocol) or CHAP (Challenge Handshake Authentication Protocol). Since credentials are sent in the clear, it is usually tunneled inside EAP-TTLS or PEAP.
- Lightweight EAP (LEAP): A username/password combination is sent to a Authentication Server (RADIUS) for authentication. LEAP consists of two MS-CHAP version 1 exchanges. One authenticates the network to the user, and the second authenticates the user to the network. Dynamic keys are derived from the two MS-CHAP exchanges.
Many of the security problems of LEAP stem from the use of MS-CHAP version 1, which has numerous security problems (like being subject to dictionary attacks).
LEAP is a proprietary protocol developed by Cisco, and is not considered secure. Cisco is phasing out LEAP in favor of PEAP.
- EAP-TLS: Creates a TLS session within EAP, between the Supplicant and the Authentication Server. Both the server and the client(s) need a valid X.509 certificate, and therefore a PKI.
This method provides mutual authentication through certificate exchanges. The user is required to submit a digital certificate to the Authentication Server for validation, but the Authentication Server must also supply a certificate for the user to validate it. The client can check the certificate validity against a list of trusted CA, thus preventing the Wireless client from associating with a rogue Wireless Access Point.
EAP-TLS provides:
- Strong cryptographic protection, by providing cryptographic protection of the session.
- Athentication of both the Supplicant and the Authentication Server, by means of using mutual authentication via X.509 digital certificates.
- Key derivation, which allows for dynamic keying and alleviates the problems derived from the fact of using static keys.
The problem with EAP-TLS is that it requires a Public Key Infraestructure, generating and signing digital certificates for both the Authentication Server and any possible Supplicant, which can make it unfeasible for small organizations which lack expertise and knowledge.
EAP-TLS is described in [RFC2716].
- EAP-TTLS: Sets up a encrypted TLS-tunnel for safe transport of authentication data. Within the TLS tunnel, (any) other authentication methods may be used.
EAP-TTLS encapsulates another authentication mechanisms. Thus, EAP-TTLS is usually called the outer authentication, while the tunneled mechanism is usually called the inner authentication.
EAP-TTLS consists of two phases:
- Phase 1: A TLS tunnel is established between the Supplicant and the Authentication Server. The X.509 digital certificate of the Authentication Server is used by the Supplicant to verify its identity and thus to validate the network authenticity.
It is very common for this phase to use an anonymous user to avoid sending any user identity in the clear, supplying the real user identity during the inner authentication.
This phase is usually called the outer authentication.
- Phase 2: The TLS tunnel is used to encrypt an older authentication protocol, like an EAP (EAP-MD5, EAP-MSCHAPv2) or non-EAP (PAP, CHAP) authentication protocol that authenticates the Supplicant to the Authentication Server and the network.
This phase is usually called the inner authentication.
The difference with respect to EAP-TLS is that only the Authentication Server is required to own a digital certificate (Supplicant certificates are optional). The Authentication Server digital certificate is used in the outer authentication, that is, in order to establish the TLS tunnel from the Supplicant to the Authentication Server.
EAP-TTLS can tunnel another inner EAP mechanism or an inner non-EAP mechanism. Some non-EAP mechanisms are:
- PAP (Password Authentication Protocol)
- PAP (Challenge Handshake Authentication Protocol)
EAP-TTLS was developed by Funk Software and Meetinghouse, and is currently an IETF draft.
- Phase 1: A TLS tunnel is established between the Supplicant and the Authentication Server. The X.509 digital certificate of the Authentication Server is used by the Supplicant to verify its identity and thus to validate the network authenticity.
- Protected EAP (PEAP): Uses, as EAP-TTLS, an encrypted TLS-tunnel. Supplicant certificates are optional, but Authentication Server certificates are required.
PEAP is very similar to EAP-TTLS, but requires the inner authentication to be another EAP exchange, that is, PEAP can only use EAP-compatible authentication methods. PEAP starts the TLS tunnel, then triggers EAP one more time, encapsulated inside the tunnel, in order to perform the authentication.
Was developed by Microsoft, Cisco, and RSA Security, and is currently an IETF draft.
- EAP-MSCHAPv2: Requires username/password, and is basically an EAP encapsulation of MS-CHAP-v2 [RFC2759]. Usually used inside of a PEAP-encrypted tunnel.
Was developed by Microsoft, and is currently an IETF draft.
Scenario
I’m going to describe how to configure a Wireless Access Point for WPA/WPA2 Enterprise.
Many modern Wireless Access Points support at least WPA Enterprise. Some do also support WPA2 Enterprise, like Apple’s AirPort Extreme Base Station and AirPort Express Base Station. I will use a D-Link DWL-AP2000+ 802.11g 2.4Ghz Wireless Access Point since it’s cheap, works well and supports WPA Enterprise.
The Supplicant (Wireless client) must also support WPA Enterprise. Mac OS X has a built-in supplicant which is WPA/WPA2 Enterprise compatible. Linux and FreeBSD have wpa_supplicant, which supports many of the EAP authentication mechanisms listed above. I will use Mac OS X built-in Supplicant.
The Authentication Server must run a RADIUS-compatible network daemon. I will use FreeRADIUS 1.0.4 as it is open source, free, works well and supports 802.1X. I will run FreeRADIUS inside an VMware Virtual Machine running Fedora Linux Core Development.
EAP-TTLS requires the use of a X.509 certificate for the RADIUS service. I will use OpenSSL to set up a Certificate Authority and generate a X.509 certificate for the RADIUS service.
I have opted to use EAP-TTLS (outer authentication) with inner PAP since it is natively supported by Mac OS X and wpa_supplicant, and it is easy to configure. The inner PAP is provided via EPA-GTC (Generic Token Card). Since PAP sends user names and passwords in the clear, it must be encapsulated inside an EAP mechanisms that provides protection against replaying, eavesdropping, etc.
Generating the X.509 certificates
For more information on setting up a Certificate Authority (CA), creating the private keys, generating the certificate requests and signing those certificates, read Setting up Certificate Authority (CA) using OpenSSL.
Creating the RADIUS X.509 certificate
Generate a new unsigned certificate and its corresponding private key:
openssl req -new -days 365 -newkey rsa:1024 -keyout /etc/pki/CA/sslkey.pem -out /etc/pki/CA/sslcert.pem
The -nodes option can be used to avoid using a pass-phrase to protect the private key. This is optional, since FreeRADIUS can use a pass-phrase protected private key with no problems at all.
Signing the RADIUS X.509 certificate
To sign this certificate:
openssl ca -in /etc/pki/CA/sslcert.pem -out /etc/pki/CA/cert.pem
Installing the RADIUS X.509 certificate
The certificate and its corresponding private key, plus the CA certificate, must be installed into /etc/raddb/certs in order to use EAP-TLS or EAP-TTLS:
Install the RADIUS private key:
mv /etc/pki/CA/sslkey.pem /etc/raddb/certs/RADIUS-key.pem
Install the RADIUS signed X.509 certificate:
mv /etc/pki/CA/cert.pem /etc/raddb/certs/RADIUS-cert.pem
Install the CA certificate:
cp /etc/pki/CA/cacert.pem /etc/raddb/certs/cacert.pem
/etc/pki/CA/sslcert.pem holds the unsigned X.509 RADIUS certificate, so it can be safely removed:
rm /etc/pki/CA/sslcert.pem
Configuring FreeRADIUS
/etc/raddb/clients.conf
The Authenticator will proxy the Supplicant authentication request to the Authentication Server. The Authenticator shares a secret, a pass-phrase, with the RADIUS server. This shared-secret is stored in the /etc/raddb/clients.conf file.
Edit /etc/raddb/clients.conf:
client 192.168.0.0/25 {
secret = TheSharedSecretBetweenRADIUSAndTheWAP
shortname = MyNetwork
}
The client directive specifies the IP subnet from which Supplicants can request authentication via 802.1X. The secret directive specifies the secret shared between the Authenticator (the Wireless Access Point) and the RADIUS server. The shortname directive is a descriptive mnemonic.
The Wireless Access Point must be configured to use WPA Enterprise. The following parameters must be configured:
- RADIUS Server IP: The IP address of the FreeRADIUS server (192.168.0.19).
- RADIUS Port: The port of the FreeRADIUS server (usually 1812/UDP).
- RADIUS Shared Secret: TheSharedSecretBetweenRADIUSAndTheWAP.
/etc/raddb/certs/random
FreeRADIUS stores 1024 bytes of entropy (randomness) in file /etc/raddb/certs/random, but since this is a configuration file, it is usually pre-established. Thus, it is a good idea to reseed it:
dd if=/dev/random of=/etc/raddb/certs/random bs=1 count=1024
/etc/raddb/eap.conf
- Change the default EAP module from EAP-MD5 to EAP-TTLS:
This can be useful if the Supplicant does not force the EAP method to be an specific one. Since Mac OS X built-in supplicant prefers EAP-TTLS with inner PAP, it is a good idea to change the default EAP method:
eap { # Invoke the default supported EAP type when # EAP-Identity response is received. # # The incoming EAP messages DO NOT specify which EAP # type they will be using, so it MUST be set here. # # For now, only one default EAP type may be used at a time. # # If the EAP-Type attribute is set by another module, # then that EAP type takes precedence over the # default type configured here. # default_eap_type = ttls - Make sure the EAP-GTC module is enabled:
PAP is tunneled inside EAP-TTLS through EAP-GTC:
gtc { # The default challenge, which many clients # ignore.. #challenge = "Password: " # The plain-text response which comes back # is put into a User-Password attribute, # and passed to another module for # authentication. This allows the EAP-GTC # response to be checked against plain-text, # or crypt'd passwords. # # If you say "Local" instead of "PAP", then # the module will look for a User-Password # configured for the request, and do the # authentication itself. # auth_type = PAP } - Enable the EAP-TLS module:
The EAP-TTLS module depends on EAP-TLS, so EAP-TLS, which is disabled by default, must be enabled:
tls { # Use private_key_password if the RADIUS private key, # stored in RADIUS-key.pem, was protected by a # pass-phrase when it was generated. # private_key_password = whatever private_key_file = ${raddbdir}/certs/RADIUS-key.pem # If Private key & Certificate are located in # the same file, then private_key_file & # certificate_file must contain the same file # name. certificate_file = ${raddbdir}/certs/RADIUS-cert.pem # Trusted Root CA list CA_file = ${raddbdir}/certs/cacert.pem dh_file = ${raddbdir}/certs/dh random_file = ${raddbdir}/certs/random # # This can never exceed the size of a RADIUS # packet (4096 bytes), and is preferably half # that, to accomodate other attributes in # RADIUS packet. On most APs the MAX packet # length is configured between 1500 - 1600 # In these cases, fragment size should be # 1024 or less. # # fragment_size = 1024 # include_length is a flag which is # by default set to yes If set to # yes, Total Length of the message is # included in EVERY packet we send. # If set to no, Total Length of the # message is included ONLY in the # First packet of a fragment series. # # include_length = yes # Check the Certificate Revocation List # # 1) Copy CA certificates and CRLs to same directory. # 2) Execute 'c_rehash '. # 'c_rehash' is OpenSSL's command. # 3) Add 'CA_path=' # to radiusd.conf's tls section. # 4) uncomment the line below. # 5) Restart radiusd # check_crl = yes # # If check_cert_cn is set, the value will # be xlat'ed and checked against the CN # in the client certificate. If the values # do not match, the certificate verification # will fail rejecting the user. # # check_cert_cn = %{User-Name} } - Enable the EAP-TTLS module, which depends on EAP-TLS:
ttls { # The tunneled EAP session needs a default # EAP type which is separate from the one for # the non-tunneled EAP module. Inside of the # TTLS tunnel, we recommend using EAP-MD5. # If the request does not contain an EAP # conversation, then this configuration entry # is ignored. default_eap_type = gtc # The tunneled authentication request does # not usually contain useful attributes # like 'Calling-Station-Id', etc. These # attributes are outside of the tunnel, # and normally unavailable to the tunneled # authentication request. # # By setting this configuration entry to # 'yes', any attribute which NOT in the # tunneled authentication request, but # which IS available outside of the tunnel, # is copied to the tunneled request. # # allowed values: {no, yes} # copy_request_to_tunnel = no # The reply attributes sent to the NAS are # usually based on the name of the user # 'outside' of the tunnel (usually # 'anonymous'). If you want to send the # reply attributes based on the user name # inside of the tunnel, then set this # configuration entry to 'yes', and the reply # to the NAS will be taken from the reply to # the tunneled request. # # allowed values: {no, yes} # use_tunneled_reply = no }The default_eap_type directive is configured so, by default, EAP-GTC (configured for PAP) is tunneled inside EAP-TTLS. This is EAP-TTLS with inner PAP.
/etc/raddb/users
This file holds the credentials for the RADIUS users. In this scenario, every Supplicant must supply valid credentials in order to be able to associate with the Wireless Access Point. Those credentials are stored in this file.
For every user, the file stores its user name and its corresponding password, via the User-Password RADIUS attribute.
A sample /etc/raddb/users file:
"testuser" User-Password == "secret" "otheruser" User-Password == "othersecret"
Testing FreeRADIUS
Once FreeRADIUS has been configured to support EAP-TTLS with inner PAP, we need to check if it starts up properly:
/usr/sin/radiusd -X
If FreeRADIUS is working properly, it should spit out something like this:
... Listening on authentication *:1812 Ready to process requests.
If so, press Ctrl+C to stop FreeRADIUS and configure it to start up automatically at next reboot, then start it as a network daemon:
chkconfig radiusd on service radiusd start
Opening the firewall
Next, punch a hole in the firewall to allow RADIUS traffic to pass in. RADIUS authentication service uses port 1812/UDP and 1812/TCP.
Edit /etc/sysconfig/iptables and add the following to lines at the end of the file, before the -j REJECT rule:
-A RH-Firewall-1-INPUT -p udp -m udp --dport 1812 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 1812 -j ACCEPT
NOTE: This assumes the default firewall configuration used by Fedora, where the INPUT and FORWARD chains are blended together into the RH-Firewall-1-INPUT chain.
Then, restart the firewall:
service iptables restart
Configuring the Supplicant
The Mac OS X Supplicant is very straightforward to set up:
- Open the Wireless preferences popup.
- Choose Other…
- Select “WPA Enterprise” from the Wireless Security dropdown.
- Choose “TTLS – PAP” from the 802.1X Configuration dropdown.
This is not needed if the EAP default module was changed from MD5 to TTLS in the /etc/raddb/eap.conf file.
- Enter the Network Name
- Enter the credentials into the User Name and Password fields.
- Click OK.
The Mac OS X Supplicant will complain that the CA certificate used to sign the RADIUS X.509 certificate is not knowm, that is, the CA certificate is not stored in the Key Ring. This is only a warning, so we can click on Continue to proceed.
The Supplicant should start the EAP-TTLS with inner PAP authentication and, after a few seconds, the Wireless network port should have associated with the Wireless Access Point.
The FreeRADIUS /var/log/radius/radius.log log file should reveal the following entries:
Info: Using deprecated naslist file. Support for this will go away soon. Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Info: Ready to process requests. Info: rlm_eap_md5: Issuing Challenge Info: rlm_eap_tls: Length Included Error: TLS_accept:error in SSLv3 read client certificate A Info: rlm_eap_tls: Length Included Info: (other): SSL negotiation finished successfully Info: rlm_eap_tls: Length Included
The “Error: TLS_accept:error in SSLv3 read client certificate A” means the Supplicant didn’t supply an X.509 client certificate. This is not exactly an error, since EAP-TTLS does not mandate Supplicants to supply an X.509 client certificate (only EAP-TLS mandates this).
felipe-alfaro.com 