802.1X Port-Based Authentication HOWTO, Lars Strand [early reader chapter books txt] 📗
- Author: Lars Strand
- Performer: -
Book online «802.1X Port-Based Authentication HOWTO, Lars Strand [early reader chapter books txt] 📗». Author Lars Strand
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 CertificatesNote 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 FreeRADIUSFreeRADIUS 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 installYou 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 = peapb. 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
Comments (0)