802.1X Port-Based Authentication HOWTO by Lars Strand (top rated ebook readers txt) 📕

>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, which uses TKIP instead of CCMP, is also called Transition Security

Network (TSN). RSN may also be called WPA2, so that the market don't get

confused.

Confused?

Basically:

��*�TSN = TKIP + 802.1X = WPA(1)

��*�RSN = CCMP + 802.1X = WPA2

In addition comes key management, as described in the previous section.

1.3. What is EAP?

Extensible Authentication Protocol (EAP) [[http://www.ietf.org/rfc/

rfc3748.txt] 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

1.4. EAP authentication methods

Since 802.1X is using EAP, multiple different authentication schemes may be

added, including smart cards, Kerberos, public key, one time passwords, and

others.

Some of the most-used EAP authentication mechanism are listed below. A full

list of registered EAP authentication types is available at IANA: [http://

www.iana.org/assignments/eap-numbers] http://www.iana.org/assignments/

eap-numbers.

Warning Not all authentication mechanisms are considered secure!

��*� EAP-MD5: MD5-Challenge requires username/password, and is equivalent to

the PPP CHAP protocol [[http://www.ietf.org/rfc/rfc1994.txt] RFC1994]. This method does not provide dictionary attack resistance, mutual authentication, or key derivation, and has therefore little use in a wireless authentication enviroment.

��*� Lightweight EAP (LEAP): A username/password combination is sent to a

Authentication Server (RADIUS) for authentication. Leap is a proprietary protocol developed by Cisco, and is not considered secure. Cisco is phasing out LEAP in favor of PEAP. The closest thing to a published standard can be found [http://lists.cistron.nl/pipermail/cistron-radius/ 2001-September/002042.html] here.

��*� 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 (x509) certificate, and therefore a PKI. This method provides authentication both ways. EAP-TLS is described in [[http://www.ietf.org/ rfc/rfc2716.txt] 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. Developed by Funk Software and Meetinghouse, and is currently an IETF draft.

��*� Protected EAP (PEAP): Uses, as EAP-TTLS, an encrypted TLS-tunnel.

Supplicant certificates for both EAP-TTLS and EAP-PEAP are optional, but server (AS) certificates are required. 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 [[http://www.ietf.org/rfc/rfc2759.txt] RFC2759]. Usually used inside of a PEAP-encrypted tunnel. Developed by Microsoft, and is currently an IETF draft.

1.5. What is RADIUS?

Remote Authentication Dial-In User Service (RADIUS) is defined in [[http://

www.ietf.org/rfc/rfc2865.txt] RFC2865] (with friends), and was primarily used

by ISPs who authenticated username and password before the user got

authorized to use the ISP's network.

802.1X does not specify what kind of back-end authentication server must be

present, but RADIUS is the "de-facto" back-end authentication server used in

802.1X.

There are not many AAA protocols available, but both RADIUS and DIAMETER

[[http://www.ietf.org/rfc/rfc3588.txt] RFC3588] (including their extensions)

conform to full AAA support. AAA stands for Authentication, Authorization,

and Accounting (IETF's AAA Working Group).

Obtaining Certificates

Note OpenSSL must be installed to use either EAP-TLS, EAP-TTLS, or PEAP!

When using EAP-TLS, both the Authentication Server and all the Supplicants

(clients) need certificates [[http://www.ietf.org/rfc/rfc2459.txt] RFC2459] .

Using EAP-TTLS or PEAP, only the Authentication Server requires certificates;

Supplicant certificates are optional.

You get certificates from the local certificate authority (CA). If there is

no local CA available, OpenSSL may be used to generate self-signed

certificates.

Included with the FreeRADIUS source are some helper scripts to generate

self-signed certificates. The scripts are located under the scripts/ folder

included with the FreeRADIUS source:

CA.all is a shell script that generates certificates based on some

questions it ask. CA.certs generates certificates non-interactively based on

pre-defined information at the start of the script.

Note The scripts uses a Perl script called CA.pl, included with OpenSSL. The

path to this Perl script in CA.all and CA.certs may need to be changed to make it work.

Tip More information on how to generate your own certificates can be found in

the SSL certificates HOWTO. Authentication Server: Setting up FreeRADIUS

FreeRADIUS is a fully GPLed RADIUS server implementation. It supports a

wide range of authentication mechanisms, but PEAP is used for the example in

this document.

3.1. Installing FreeRADIUS

Installing FreeRADIUS

Head over to the FreeRADIUS site, [http://www.freeradius.org/] http://

www.freeradius.org/, and download the latest release.

# cd /usr/local/src

# wget ftp://ftp.freeradius.org/pub/radius/freeradius-1.0.0.tar.gz

# tar zxfv freeradius-1.0.0.tar.gz

# cd freeradius-1.0.0

Configure, make and install:

# ./configure # make # make install

You can pass options to configure. Use ./configure --help or read the

README file, for more information.

The binaries are installed in /usr/local/bin and /usr/local/sbin. The

configuration files are found under /usr/local/etc/raddb.

If something went wrong, check the INSTALL and README included with the

source. The [http://www.freeradius.org/faq/] RADIUS FAQ also contains

valuable information.

3.2. Configuring FreeRADIUS

FreeRADIUS has a big and mighty configuration file. It's so big, it has

been split into several smaller files that are just "included" into the main

radius.conf file.

There is numerous ways of using and setting up FreeRADIUS to do what you

want: i.e., fetch user information from LDAP, SQL, PDC, Kerberos, etc. In

this document, user information from a plain text file, users, is used.

Tip The configuration files are thoroughly commented, and, if that is not

enough, the doc/ folder that comes with the source contains additional information.

Configuring FreeRADIUS

The configuration files can be found under /usr/local/etc/raddb/

# cd /usr/local/etc/raddb/

Open the main configuration file radiusd.conf, and read the comments!

Inside the encrypted PEAP tunnel, an MS-CHAPv2 authentication mechanism

is used.

a. MPPE [[http://www.ietf.org/rfc/rfc3078.txt] RFC3078] is responsible

for sending the PMK to the AP. Make sure the following settings are set: # under MODULES, make sure mschap is uncommented! mschap { # authtype value, if present, will be used # to overwrite (or add) Auth-Type during # authorization. Normally, should be MS-CHAP authtype = MS-CHAP # if use_mppe is not set to no, mschap will # add MS-CHAP-MPPE-Keys for MS-CHAPv1 and # MS-MPPE-Recv-Key/MS-MPPE-Send-Key for MS-CHAPv2 # use_mppe = yes # if mppe is enabled, require_encryption makes # encryption moderate # require_encryption = yes # require_strong always requires 128 bit key # encryption # require_strong = yes authtype = MS-CHAP # The module can perform authentication itself, OR # use a Windows Domain Controller. See the radius.conf file # for how to do this. }

b. Also make sure the "authorize" and "authenticate" contains:

authorize { preprocess mschap suffix eap files } authenticate { # # MSCHAP authentication. Auth-Type MS-CHAP { mschap } # # Allow EAP authentication. eap }

Then, change the clients.conf file to specify what network it's

serving:

# Here, we specify which network we're serving

client 192.168.0.0/16 {

# This is the shared secret between the Authenticator (the # access point) and the Authentication Server (RADIUS). secret = SharedSecret99 shortname = testnet }

The eap.conf should also be pretty straightforward.

a. Set "default_eap_type" to "peap":

default_eap_type = peap

b. Since PEAP is using TLS, the TLS section must contain:

tls { # The private key password private_key_password = SecretKeyPass77 # The private key private_key_file = ${raddbdir}/certs/cert-srv.pem # Trusted Root CA list CA_file = ${raddbdir}/certs/demoCA/cacert.pem dh_file = ${raddbdir}/certs/dh random_file = /dev/urandom }

c. Find the "peap" section, and make sure it contain the following:

peap { # The tunneled EAP session needs a default # EAP type, which is separate from the one for # the non-tunneled EAP module. Inside of the # PEAP tunnel, we recommend using MS-CHAPv2, # as that is the default type supported by # Windows clients. default_eap_type = mschapv2 }

The user