802.1x components

The “802.1x” standard allows authentication of devices in LAN or Wireless networks, using cryptographic techniques to provides higher security. 802.1x can authenticate the user or the device.

FreeNAC includes 802.1x since V2.2.

802.1x and MAC address identification can be combined, by for example authenticating the user via Windows Domain Logon and using the end-device MAC address for Vlan assignment.

The following diagram shows the components involved in 802.1x authentication.

The VMPS/MAC based components (vmpsd_external, postconnect) are documented in the VMPS section.

rad2vmps

A Perl script 'rad2vmps' is called from FreeRadius, that accepts a MAC address and returns the Vlan to be assigned to the supplicant. This script queries the FreeNAC database of MAC addresses via the VMPS protocol.

802.1x problems

802.1x provides key advantages such as added security and a consensus that long term it is 'the way to go', but keep in mind some of the limitations when choosing 802.1x over VMPS in the short term.

• New(er) switches are usually required (e.g. 2006 or later)
• Vendor interoperability is a problem, each implements their own additional radius fields.
• Its a complex protocol: it is slower (due to the amount of data exchanges, the number of handshakes and encryption), difficult to analyse and support (due to the complexity of handshakes).
• Supplicants (the 802.1x client) are delivered with some Operating Systems but not with others. In Windows, depending on patch level/Service pack, it may work fine. 3rd party supplications are available but usually are not free and require configuration, suppport and distribution.
• Certificate (PKI) management: generating and checking signatures is normally easy enough, but how do you distribute, revoke and check for revoked certificates? How large are CRLs, how/where are they managed/downloaded?
• Interaction with Hubs, un-managed switches and Virtual Machines in bridged mode can be problematic, as 802.1x usually expects only one end-device per port.
• Cost: due to the above and the cost of a commercial Radius server (if you don't use a free alternative such as FreeRadius/FreeNAC)

Generation of computer certificates with a Winbugs CA

Generation of computer certificates with a Winbugs CA

If you want to deploy EAP-TLS in your network and require end-device certificates installed on your computers, this guide might be of help. In this guide we are going to generate computer certificates and configure the computer to perform EAP-TLS by using this certificate. Important: we won't be validating the users, only the device, so it means that any user can use the computer as long as the certificate is valid.

To generate the certificates, we will use a web server running Windows Server 2003 with the service of certification authority (CA) installed.

Open your favorite web browser and type in http://your_server/certsrv/, where your_server is the DNS name or IP address of your web server.

"Request a certificate", ask for an "advanced certificate request" and "Create and submit a certificate request to this CA".

In the Name field, type in the name of the computer for which you are requesting this certificate.

In Type of certificate needed, select "Client Authentiation Certificate"

Create a new key set and as Key Usage select "both".

Select the Mark Keys as exportable check box. Doing this saves the public and private key to a PKCS #12 file. This is useful if you want to copy a certificate for use on another computer.

Select the Store certificate in the local computer certificate store check box. This last option is actually important because it will save the certificate in the computer store, instead of the user store, which allows for TLS authentication to work.

Then you just need to wait for your CA to issue the certificate for you. Once you have your certificate, install it. By default it should be stored in the computer store.

Now, to allow EAP-TLS to work using this certificate as a computer certificate for all users, you need to modify the registry of the computer where you installed the certificate on. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EAPOL\Parameters\General\Global and add a new DWORD-value called AuthMode with the value of 2. Note that for this you need to have Administrator privileges on the computer.

Now you need to restart either your computer or the Wireless Zero Configuration service and you are done. This will perform the magic needed to send the computer certificate to authenticate this computer regardless of what user is actually using it.

Generation of server certificates with OpenSSL and a Winbugs CA

Generation of certificates for FreeRadius (EAP-TLS) with a CA on a Winbugs box

When generating certificates to be used by FreeRadius with EAP-TLS, there is an extension which is to be added to the certificate in order to validate this certificate. This validation is performed by the client against a root CA certificate. If such extension is not present in your FreeRadius server certificate, the auth process will fail, because the client won't be able to validate it and stop communicating with your server. If you happen to have your CA running in a Winbugs box, then this might be of help. We are going to generate a request using openssl and issue the certificate with winbugs with the extension needed embeded into the cert file.

First of all, in the computer where you are going to generate the request, edit your openssl.cnf file and do the following modifications:

Find the v3_req stanza and change the following line:

keyUsage = nonRepudiation, digitalSignature, keyEncipherment

for this one

keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment

and add the following line at the end of this stanza

extendedKeyUsage = 1.3.6.1.5.5.7.3.1

This will generate a request containing all needed attributes/extensions to be validated by the clients.

Your v3_req stanza should look like the following:

[ v3_req ]
 # Extensions to add to a certificate request
 basicConstraints = CA:FALSE
 keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
 extendedKeyUsage = 1.3.6.1.5.5.7.3.1

Bear in mind that you are modifying openssl's configuration file. That means that all future requests will have these attributes set. If you don't want all future request to be a server authentication request, comment the last line out from the v3_req stanza.

Now generate your request using openssl

openssl req -new -keyout server.key -out server.req

This generates two files. One where your private key is contained and another one with your actual request. OpenSSL will ask you for a pass phrase. The passphrase you enter here is important. Without it you won't be able to decode your private key.

Our CA is on a Win2k3 server. We need to send our request to the CA by using the Microsoft Certificate Services. Open your favorite browser, and type in http://your_server/certsrv/ and select "Request a certificate" and submit an "advanced certificate request" by using the base-64-encoded option.

Once the page is open, copy the contents of your server.req file and press submit. Then you just need to wait for your CA to issue the certificate for you.

If you need your certificate in PEM format and the certificate was exported as DER encoded there is a final step you have to perform.

openssl x509 -inform DER -in certificate.cer -outform PEM -out certificate.pem

If the certificate is Base-64 encoded and you need the PEM extension, then just rename the file.

mv certificate.cer certificate.pem

eap.conf

The eap.conf configuration file deals with the settings needed to perform cryptographic operations. The default eap.conf file that comes with your default installation provides enough information to help you configure your system properly, here we are presenting some common options, what they mean and how to configure them.

The tls section

This section holds configuration settings that affect your RADIUS server, so be careful when editting these settings.

private_key_password

The password you used to encode your private key when generating your certificate request. Comment it out if no password was set.

private_key_file

Path to your private key file. It has to be in PEM format

certificate_file

Path to your actual server certificate also in PEM format

If Private key & Certificate are located in the same file, then private_key_file & certificate_file must contain the same file name.

CA_file

Trusted Root CA list. To use a certificate chain, you need to append in this file all certificates of the CAs that take part in your certificate chain, starting with the one that is at the top of the chain and finishing with the one that signed your certificate. This file has to be in PEM format.

check_crl

Set it to yes if you are going to use revocation lists, or comment it out if you won't.

CA_path

Path to the directory where the revocation list is. If you are not using CRLs, comment this out.
Copy to this directory the RL and your trusted root CA list. Once you've done that, do a c_rehash to this directory, where c_rehash is an OpenSSL command. Remember that CRLs have an expiry date, so make sure to always refresh your CRLs otherwise your server will deny all requests.

check_cert_issuer 

If check_cert_issuer is set, the value will be checked against the DN of the issuer in the client certificate. If the values do not match, the cerficate verification will fail, rejecting the user.

check_cert_cn

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.

This check is done only if the previous "check_cert_issuer" is not set, or if the check succeeds.

If you are using computer certificates, the username is sent like 'host//pc001' and the verification might fail because of the 'host//' part. In such a case, you might want to strip that part by doing:

check_cert_cn = %{Stripped-User-Name:-%{User-Name}} 

 

MAC-Auth-Bypass

MAC authentication bypass is an alternative to 802.1X that allows network access to devices (such as printers and IP phones) that do not have the 802.1X supplicant capability. MAC authentication bypass uses the MAC address of the connecting device to grant or deny network access.

MAC-Authentication bypass in FreeRadius, using FreeNAC as backend works as follows:

• When a device connects to the switch, the connecting device normally sends an "Access-Request" packet to the switch, which is then forwarded to the Authentication Server, in our case, FreeRadius.
  Then the Authentication server asks for more information from the connecting device in form of Access-Challenges. This process continues until the Radius server has enough information (Radius attributes) to make a decision.
  After requesting all required Access-Challenges from the connecting device, FreeRadius will give back to the switch an Access-Accept or an Access-Reject response, where this decision will be enforced.
• An 802.1x capable device selects the authentication type that will be used to perform uthentication by means of a Radius attribute. Checking this Radius attribute, FreeRadius will know how to authenticate the username, for example, by using Samba, MySQL, LDAP, etc.
• When a non-802.1x-capable device connects to the switch, the switch detects that one of its links is up and waits for packets which will then be forwarded to FreeRadius. If during a certain amount of time the switch hasn't received any packets, it will start authentication of the connecting device using its MAC address as the username. FreeRadius will then generate a VMPS request for
  FreeNAC, and FreeNAC will say if the device is authorized or not and where to place it.

In FreeNAC, we use a module called rad2vmps which performs the translation of a RADIUS request into a VMPS request which is then sent to the VMPS server. rad2vmps is a modification to the original script vqpcli.pl part of the OpenVMPS distribution. Vqpcli.pl makes VMPS requests to a VMPS server and outputs the decision taken by the VMPS server.

In the authorize section of FreeRadius, rad2vmps retrieves the needed parameters from the RADIUS request to make a VMPS request, (e.g. Switch IP, MAC address, etc). When a request reaches FreeRadius and no authentication type has been specified, rad2vmps will output the required attributes to call for MAC-Authentication bypass.

In the Authentication section of FreeRadius, the authentication type corresponding to this request will be used. For example, if in the request the authentication type was specified to MSCHAP, MSCHAP authentication will be called. For MAC-Authentication bypass, it is here where we create our VMPS request and send it to the VMPS server.

After we know who the user is (authenticate section), we assign the device the vlan where it belongs to. For all authentication types but MAC-Authentication bypass, it is here where we create our VMPS request and send it to the VMPS server. If a MAC-Authentication bypass was done, the code in this section is ignored.

So, basically, the difference between a MAC-authentication bypass and the rest of the authentication types is where we send the VMPS request. For MAC-Authentication bypass, the request is sent in the Authenticate part, and for the rest in the Post-Auth section. This allows for authenticating the user before authenticating her device.

Authenticating both username and device is more secure than authenticating only the device, but in cases where this is not possible, MAC-Authentication bypass is used.

Links to 802.1x material on this website

Links to other Technical Guide Documentation

• Switch configuration: Cisco 802.1x tests

Links to the Install Guide:

• Building 802.1x components