RSA SecurID Authentication

RSA SecurID is two-factor authentication mechanism. This authentication mechanism primarily involves three components: • RSA SecurID Authenticator token (hardware based or software based) that generates a unique authentication code

• RSA SecurID Server (Authentication Manager)
• RSA Authentication Agent

RSA SecurID Authenticator Token and Code

Each RSA SecurID token includes a factory-encoded, unique ‘seed.’ The token uses this unique seed to generate an authentication code at fixed intervals (for example 60 seconds). By utilizing the built-in-clock time and the unique seed, the authentication code keeps changing at fixed intervals. Since the token’s clock and the server’s clock are synchronized. the server generates authentication codes at the same fixed intervals as the token. Possession of the resulting code is then combined with knowledge of a PIN number to produce secure authentication.

RSA SecurID Server

Users are authenticated against the RSA SecurID Server with the username and the passcode, which is the combination of the authentication code generated/displayed by the token and the PIN (see above).

The first time a user uses the token, they are asked to choose a new PIN. The server also requests a new time-synchronous PIN regularly or whenever the timing between a token and a server ‘drifts.’ If the drift is more than 3 minutes, then the Server requests the user to enter the next authentication code generated by the token in the next interval to verify the possession of the token. If the next authentication mode has the same clock drift, then token is assumed valid by the Server.

RSA SecurID Agent

This authentication is similar to the standard username-passcode authentication, but the passcode is not a single word. It is a numeric combination of the authentication code in the token and the PIN known to the user.

The RSA SecurID can be achieved two ways:

• EAP-RSA based authentication – implemented currently
• Native SecurID Authentication – not in use at this time

RSA SecurID Authentication

Configure RSA SecurID

Communication between an RSA server and a controller is the same as communication between a controller and any other RADIUS server (IAS or Free RADIUS). The only difference is in the way the client authenticates to the RSA Server, by means of two factor authentication in which Fortinet does not interfere. Configure an RSA server on a controller using the CLI command radius-profile. For example:

default# configure terminal default(config)# radius‐profile <RSA>

default(config‐radius)# ip‐address <IP of the RSA server> default(config‐radius)# key secure‐secret default(config‐radius)# exit

Policy Enforcement Module

The optional Policy Enforcement Module feature makes it possible to control network content by dropping/allowing traffic based on configured policies applied on a firewall tag associated with a user group. This includes Captive Portal users in release 3.7 and later.

Policy Enforcement Module

Fortinet’s firewall is generic, and can be used to prevent any subnet to subnet communication, for specific ports or all ports. With the Filter ID, we can also prevent any user from any SSID from accessing specific subnets.

The per-user firewall filtering is implemented either by:

• A RADIUS-returned filter-id attribute, that is created on the RADIUS server and assigned to users
• A configured firewall filter-id parameter that is part of the Security profile configuration and is applied to clients associated with an ESS

For the RADIUS-based per-user firewall, the returned filter-id attribute is part of AccessAccept message returned for a user, and is used as the firewall tag. The filtering action is determined by the configured firewall polices for this firewall tag.

In the absence of a RADIUS configuration, a configured firewall tag in the Security profile can be used for defining the filtering based on the configured firewall polices. In this case, all users connecting to a given ESS profile are allocated the same firewall tag as configured for the profile.

For successful operation using a RADIUS configuration, the Filter-id attribute that is configured on the RADIUS Server must match that used on the controller. In some RADIUS Servers, a Filter ID must be created.

The policies that filter the traffic are created using the standard QoS qosrule configuration, and the inherent priorities and configuration parameters are described in detail in Chapter 15 of this manual as well as in the qosrule entry in the FortiWLC (SD) Command Reference.

Configure Firewall Policies with the CLI

Begin the Policy Enforcement Module configuration by configuring a set of qosrule policies to manage the traffic.

The following example shows the creation of qosrule 200 as a policy for Firewall filter-id 1:

default# configure terminal default(config)# qosrule 200 netprotocol 6 qosprotocol none default(config)# netprotocol‐match default(config‐qosrule)# dstport 80 default(config‐qosrule)# dstport‐match on default(config‐qosrule)# action drop default(config‐qosrule)# firewall‐filter‐id 1 default(config‐qosrule)# firewall‐filter‐id‐match on default(config‐qosrule)# qosrule‐logging on default(config‐qosrule)# qosrule‐logging‐frequency 30

Policy Enforcement Module

default(config‐qosrule)# exit default(config)# exit

To check the configuration of the policy, use the show qosrule command:

default# show qosrule

ID    Dst IP          Dst Mask        DPort Src IP          Src Mask        SPort Prot QoS   Action   Drop  Firewall Filter

• 0.0.0 0.0.0.0         1720  0.0.0.0         0.0.0.0         0     6    h323  capture  head       
• 0.0.0 0.0.0.0         0     0.0.0.0         0.0.0.0         1720  6    h323  capture  head                 
• 0.0.0 0.0.0.0         5060  0.0.0.0         0.0.0.0         0     17   sip   capture  head                 
• 0.0.0 0.0.0.0         0     0.0.0.0         0.0.0.0         5060  17   sip   capture  head                 
• 0.0.0 0.0.0.0         5200  0.0.0.0         0.0.0.0         0     17   none  forward  head                 
• 0.0.0 0.0.0.0         0     0.0.0.0         0.0.0.0         5200  17   none  forward  head                 

200   0.0.0.0         0.0.0.0         80    0.0.0.0         0.0.0.0         0     6    none  drop     tail  1              

        QoS Rules(7 entries) default#

The following commands are required to apply the example filter ID 1 to the Security Profile.

default(config‐security)# firewall‐capability configured default(config‐security)# firewall‐filter‐id  1 default(config‐security)# security‐logging off

Once you create a firewall rule, you cannot modify the rule to enable or disable firewall logging. As a workaround, either create the firewall rule with the required option or delete the rule and re-apply it with the required option.

Troubleshooting Per-User Firewall

• Turn on the QoS rule logging feature available in QoS rule page. If the client traffic hits the rule, the same will be displayed in the syslog server or via the CLI command show syslogfile firewall.

Policy Enforcement Module

For command details, see the FortiWLC (SD) Configuration Guide.

Example Security Profile with 802.1X RADIUS

In the following example, the Security Profile 8021x-data is created. It supports 802.1X authentication and uses the RADIUS profile main-auth to enable the primary RADIUS authentication server and the backup-auth profile for the secondary RADIUS server.

default(config)# security-profile 8021x-data default(config‐security)# allowed-l2-modes 802.1x default(config‐security)# radius‐server primary main‐auth default(config‐security)# radius‐server secondary backup‐auth default(config‐security)# exit default(config)# exit

802.1X PTK Rekey

With the 802.1X PTK rekey feature, whenever the rekey interval expires, the Access Point sends a unicast key and a broadcast key to the client. These two key packets are NOT encrypted.

To enable 802.1X PTK rekey, enter the following command from the Security Profile configuration: (n can be from 0 to 65535 (60 minutes), and is specified in seconds) default(config‐security)# rekey period n

To disable 802.1X PTK rekey, enter the following command from the Security Profile configuration:

default(config‐security)# rekey period 0

802.1X GTK Rekey

To configure the 802.1X GTK rekey period, from the Security Profile configuration, add the following command (the rekey period is specified in seconds): default(config‐security)# group-rekey interval n

To disable 802.1X GTK rekey, enter the following command from the Security Profile configuration:

default(config‐security)# no group-rekey interval

802.1X RADIUS Server Command Summary

The following commands are used to configure the RADIUS servers:

TABLE 14: Commands to Configure the 802.1X RADIUS Servers

TABLE 15: Commands Used to Create Security Profiles

TABLE 15: Commands Used to Create Security Profiles

Configure WPA2 With the CLI

The controller supports the WPA2 standard that includes CCMP encryption which is considered extremely secure. Implementing WPA2 provides the highest level of security that the Fortinet Wireless LAN System offers.

Additionally, if 802.1X is implemented at the site, automatic key exchange is provided by the RADIUS server. Existing primary and secondary RADIUS Server Profiles can be assigned from within the Security Profile to leverage the existing 802.1X authentication. Otherwise, the WPA2-PSK configuration can be implemented.

Example WPA2 Configuration

To configure WPA2 security with the Web UI, click Configuration > Security > Profile. Click Help for option details.

The following CLI example creates the profile named wpa2-ccmp that enables WPA2 for Layer 2, sets the encryption mode to CCMP-AES, and names the RADIUS server in the mainauth profile as the primary RADIUS authentication server.

default(config)# security-profile wpa2-ccmp default(config‐security)# allowed-l2-modes wpa2 default(config‐security)# encryption‐modes ccmp default(config‐security)# radius‐server primary main‐auth default(config‐security)# exit default(config)# exit

Example WPA2-PSK Configuration

To configure security with the Web UI, click Configuration > Security > Profile. Click Help for option details.

When setting the PSK key with the CLI, use a key from 8 to 63 ASCII characters (the characters ! \ ” ?  must be escaped with the backslash (\) character; for example \! \?) or 64 hex characters (hex keys must be prefixed with “0x” or the key will not work).

The following example creates the profile named wpa2-psk that enables WPA2-PSK for Layer 2, sets the encryption mode to CCMP, and sets the preshared key to theSecretKeyForNov28.

default(config)# security-profile wpa2-psk default(config‐security)# allowed-l2-modes wpa2-psk default(config‐security)# encryption‐modes ccmp default(config‐security)# psk key theSecretKeyForNov28 default(config‐security)# exit default(config)# exit

Opportunistic PMK Caching for WPA

Opportunistic PMK caching allows the controller, acting as the 802.1X authenticator, to cache the results of a full 802.1X authentication so that if a client roams to any AP associated with that controller, the wireless client needs to perform only the 4-way handshake and determine new pair-wise transient keys. PMK caching is supported only for KDDI phones when using WPA with TKIP and 802.1X authentication.

The system automatically detects the KDDI phone using the KDDI Vendor ID and applies PMK caching if available.

From with the Security Profile configuration, enable or disable PMK caching for KDDI phones. This option is only available when WPA is chosen for L2 encryption.

To enable PMK caching, add the following line to the WPA Security Profile configuration: default(config‐security)# pmkcaching enabled

To disable PMK caching, execute the following command at the WPA Security Profile configuration:

default(config‐security)# pmkcaching disabled

Configure 802.11 WEP Encryption

The controller supports two WEP cypher suites: WEP128 and WEP64.

The key configuration parameters allow the setting of the mutually shared key and the choice of key slot positions from 1 to 4, as allowed by most user key configuration programs.

Example 802.11 WEP Configuration

The following example creates the profile named wep- that supports a static 128-bit WEP encryption for  users. The static WEP key is defined as  and uses the third key index position on a user station’s WEP key definition.

default(config)# security-profile wepdefault(config‐security)# allowed-l2-modes wep default(config‐security)# encryption-modes wep128 default(config‐security)# static-wep key default(config‐security)# static-wep key-index 3 default(config‐security)# exit default(config)# exit default#

802.11 WEP Command Summary

The following summarizes the commands that can be used to configure 802.11 WEP security.

TABLE 16: Commands to Configure 802.11 WEP Security

Checking a CLI Configuration

To view all Security Profiles currently configured, use the show security-profile command.

# sh security‐profile

Profile Name                     L2 Mode        Data Encrypt Firewall Filter

default                          clear          none      captive‐portal                   clear          none         wep                              wep            wep64        802.1x                           802.1x         wep128        wpa                              wpa            tkip         wpapsk                           wpa‐psk        tkip         wpa2                             wpa2           ccmp         wpa2psk                          wpa2‐psk       ccmp        

        Security Profile Table(8)

To view the details of an individual Security Profile, use the show security-profile profile-name command.

default# show security-profile wpa-leap

Security Profile Table

Security Profile Name                                  : wpa‐leap

L2 Modes Allowed                                       : 802.1x

Data Encrypt                                           : none

Primary RADIUS Profile Name                            : ACS‐87‐8#

Secondary RADIUS Profile Name                          :

WEP Key ASCII:(default) 13 chars / 0x:26 chars         : *****

Static WEP Key Index                                   : 1

Re‐Key Period (seconds)                                : 0

Enable Multicast Re‐Key                                : off

Captive Portal                                         : disabled

802.1X Network Initiation                              : on

Tunnel Termination                                     : PEAP, TTLS

Shared Key Authentication                              : off

Pre‐shared Key (Alphanumeric/Hexadecimal)              : *****

Group Keying Interval (seconds)                        : 0

PMK Caching                                            : disabled

Key Rotation                                           : disabled

Reauthentication                                       : off MAC Filtering                                          : off

Firewall Capability                                    : none

Firewall Filter ID                                     :

Security Logging                                       : off

Use the commands show web login-page and show web custom-area to find out what set of web pages are used for Captive Portal and WebAuth.

Configure a Security Profile With the CLI

The controller supports the ability to define multiple Security Profiles that can be assigned to different wireless LAN extended service sets (ESS) according to the level and type of security required. A Security Profile is a list of parameters that define how security is handled within an ESS. With Security Profiles, you can define the Layer 2 security method, including the cipher suite, primary and secondary RADIUS server, static WEP key entries and key index position, and other parameters. The various Security Profiles you create allow you to support multiple authentication and encryption methods within the same WLAN infrastructure.

The controller is shipped with OPEN authentication, meaning that there is no authentication, and that any wireless client can connect to the controller. These setting are defined in the default Security Profile named default.

You can view the default Security Profile using the show security-profile default command.

default# show security-profile default

Security Profile Table

Security Profile Name                                  : default

L2 Modes Allowed                                       : clear

Data Encrypt                                           : none

Primary RADIUS Profile Name                            :

Secondary RADIUS Profile Name                          :

WEP Key (Alphanumeric/Hexadecimal)                     : *****

Static WEP Key Index                                   : 1

Re‐Key Period (seconds)                                : 0

Captive Portal                                         : disabled

802.1X Network Initiation                              : off

Tunnel Termination                                     : PEAP, TTLS

Shared Key Authentication                              : off

Pre‐shared Key (Alphanumeric/Hexadecimal)              : *****

Group Keying Interval (seconds)                        : 0

PMK Caching                                            : disabled

Key Rotation                                           : disabled

Reauthentication                                       : off MAC Filtering                                          : off

Firewall Capability                                    : none

Firewall Filter ID                                     :

Security Logging                                       : off

Passthrough Firewall Filter ID)                        :

The default Security Profile is configured to allow “clear” Layer 2 access with no authentication method, encryption, or cipher suite specified.

The Tunnel Termination is configured separately for PEAP and TTLS.

Configure 802.1X RADIUS Security With the CLI

To allow WLAN access to your site’s 802.1X authorized and authenticated users, set up 802.1X RADIUS authentication. To do this:

• Create a global RADIUS Server Profile that specifies how to communicate with the primary RADIUS server in your network. If an optional secondary RADIUS server is to be used, a separate profile is also created for it.
• Create a Security Profile for the ESS that configures 802.1X Layer 2 security and assigns a primary RADIUS profile and optional secondary RADIUS profile

Refer to your RADIUS server documentation regarding how to configure the type of EAP protocol for your site and the procedure for installing any necessary certificates. The actual RADIUS server configuration is not covered here, only the configuration for enabling the communication between the RADIUS server and the controller is described.

The following commands set up a profile for the primary RADIUS server, main-auth, that specify the server’s IP address and secret key. All other default parameters (such as the port number (1812)) are acceptable, and not changed:

default# configure terminal default(config)# radius‐profile main‐auth default(config‐radius)# ip-address 10.1.100.10 default(config‐radius)# key secure-secret default(config‐radius)# exit

For additional reliability, configure a secondary RADIUS Server Profile to serve as a backup should the primary server become unavailable.

default# configure terminal default(config)# radius‐profile backup‐auth default(config‐radius)# ip-address 10.1.100.2 default(config‐radius)# key secure-secret2 default(config‐radius)# exit

Next, create the Security Profile that enables 802.1X and points to the profiles that describe the RADIUS primary and secondary servers.

Configure GRE Tunnels

The GRE tunneling provides packet isolation from one endpoint to another, encapsulated within an IP tunnel to separate user traffic.

GRE Tunneling facilitates configurations as shown in Figure 44, where guest users who are logged into a guest ESS are given “guest” Internet access at Level 1 and have their traffic separated from corporate users who are on a common shared link to the corporate campus. Contract users have similar connection as corporate users but are restricted in access to certain sites by user firewall policies.

GRE tunneling provides an option to segregate users’ traffic by allowing an ESS profile to be tied to a GRE profile. This provides an alternative to VLANs for segregating traffic.

Configure GRE Tunnels

Figure 44: Example GRE Tunneling Configuration

To configure GRE tunneling, create the GRE tunnel profile as well as an ESSID that specifies the GRE tunnel and also references a Security Profile. GRE can also be configured from E(z)RF Network Manager.

All IP addresses configured for the tunnel must be unique; these IP addresses define the endpoints of the tunnel, with the controller FastEthernet IP address defining the local endpoint and the ip remote-external-address specifying the remote endpoint.The ip tunnel-ip-address defines the tunnel network.

If the GRE Tunnel is to be configured on the second interface of a Dual-Ethernet configuration, be sure to configure the second Ethernet interface, as described in the section “Configuring an Active Interface” on page 201”.

The following example shows the commands for configuring a GRE tunnel profile on the second FastEthernet interface, where the IP address of the tunnel’s local endpoint is 13.13.13.13 and the remote endpoint is 172.27.0.206, and the DHCP server is at 10.0.0.12:

default(config)# gre guest default(config‐gre)# interface FastEthernet controller 2 default(config‐gre)# ip tunnel‐ip‐address 13.13.13.13 255.255.255.0 default(config‐gre)# ip remote‐external‐address 172.27.0.206 default(config‐gre)# ip dhcp‐override    default(config‐gre)# ip dhcp‐server 10.0.0.12 default(config‐gre)# end

Configure GRE Tunnels

To check the configuration of the GRE tunnel, use the show gre command:

default# show gre

GRE Name   Remote External Address   Tunnel IP address   Tunnel IP Netmask

LocalExternal

vlan1      172.27.0.162               12.12.12.12          255.255.0.0

1

gre1       172.27.0.206               13.13.13.13          255.255.0.0

2

         GRE Configuration(2 entries)

To configure the GRE ESSID, specify the GRE profile name, a tunnel-type and Security Profile, as shown in the following example:

default(config)# essid guest default(config‐essid)# gre name guest default(config‐essid)# tunnel‐type gre default(config‐essid)# security‐profile default default(config)# exit

• The GRE ESSID name must be the same as the GRE Tunnel Profile name specified in the preceding GRE Configuration procedure (for example, guest). The GRE Tunnel Profile name is specified in the gre name.
• For the tunnel-type, the gre parameter must be specified for GRE Tunnel configuration.
• Specify the Security Profile name with the security-profile command—typically the default profile is used.

To check the status of the a GRE tunnel, use the command: default# test gre gre_name ip_address

where gre_name is the GRE Profile name and ip_address is the IP address of the machine that is connected behind the tunnel (optional).

The following points should be noted when configuring a GRE tunnel:

• The DHCP relay pass-through flag always should be off for a GRE tunnel. This ensures the

DHCP relay is always on and hence the DHCP request packets are forwarded to the DHCP Server specified by DHCP Server IP Address.

• DHCP traffic associated with users connecting to a GRE tunnel are relayed to the configured DHCP Server located at the remote location through the associated GRE tunnel.

Configure GRE Tunnels

• Only IPv4 support is provided for GRE tunneling.

Limitations of the WEP Protocol

WEP is vulnerable because the relatively short IVs and keys remain static. Within a short amount of time, WEP eventually uses the same IV for different data packets. For a large busy network, the same IVs can be used within an hour or so. This results in the transmitted frames having key streams that are similar. If a hacker collects enough frames based on the same IV, the hacker can determine the shared values among them (the key stream or the shared secret key). This can allow to the hacker to decrypt any of the 802.11 frames.

A major underlying problem with the existing 802.11 standard is that the keys are cumbersome to change. The 802.11 standard does not provide any functions that support the exchange of keys between stations. To use different keys, an administrator must manually configure each access point and radio NIC with a new common key. If the WEP keys are not updated continuously, an unauthorized person with a sniffing tool can monitor your network and decode encrypted frames.

Despite the flaws, you should enable WEP as a minimum level of security. Many hackers are capable of detecting wireless LANs where WEP is not in use and then use a laptop to gain access to resources located on the associated network. By activating WEP, however, you can at least minimize this from happening. WEP does a good job of keeping most honest people out.

Operation of the WEP Protocol

If a user activates WEP, the NIC encrypts the payload, which consists of the frame body and cyclic redundancy check (CRC), of each 802.11 frame before transmission using an RC4 stream cipher provided by RSA Security. The receiving station, such as an access point or another radio NIC, performs decryption when it receives the frame. As a result, 802.11 WEP only encrypts data between 802.11 stations. Once the frame enters the wired side of the network, such as between access points, WEP no longer applies.

As part of the encryption process, WEP prepares a key schedule (“seed”) by concatenating the shared secret key supplied by the user of the sending station with a randomly-generated 24-bit initialization vector (IV). The IV lengthens the life of the secret key because the station can change the IV for each frame transmission. WEP inputs the resulting “seed” into a pseudo-random number generator that produces a key stream equal to the length of the frame’s payload plus a 32-bit integrity check value (ICV).

The ICV is a checksum that the receiving station later recalculates and compares to the one sent by the sending station to determine whether the transmitted data underwent any form of tampering while in transit. In the case of a mismatch, the receiving station can reject the frame or flag the user for potential security violations.

With WEP, the sending and receiving stations use the same key for encryption and decryption. WEP specifies a shared 40- or 104-bit key to encrypt and decrypt data (once the 24-bit IV is added in, this matches FortiWLC (SD)’s 64- or 128-bit WEP specification, respectively). Each radio NIC and access point, therefore, must be manually configured with the same key.

Before transmission takes place, WEP combines the key stream with the payload and ICV through a bit-wise XOR process, which produces cipher text (encrypted data). WEP includes

Encryption Support

the IV in the clear (unencrypted) within the first few bytes of the frame body. The receiving station uses this IV along with the shared secret key supplied by the user of the receiving station to decrypt the payload portion of the frame body.

Encryption Support

Wireless LAN System offers CCMP-AES for WPA2. WPA2 uses CCMP/AES as encryption method. Descriptions of these technologies are provided in this section. Fortinet also supports the original 802.11encryption protocols provided by WEP64 and WEP128.

We recommend using the more secure CCMP-AES encryption solution if your site’s client hardware cannot support CCMP.

CCMP-AES

AES is the Advanced Encryption Standard and is used by the US Department of Defence as a replacement for older encryption standards. As such, it is very secure. AES can be used in several modes, and CCMP is the mode used by WPA2. Both terms are commonly used interchangeably.

WEP Security Features

Wired Equivalent Privacy (WEP64 and WEP128) is a Layer 2 security protocol specified in the IEEE Wireless Fidelity (Wi-Fi) standard, 802.11. WEP is designed to provide a wireless LAN with comparable level of security and privacy to what is usually expected of a wired LAN. A wired LAN is generally protected by physical security mechanisms, such as controlled access to a building, that are effective for a controlled physical environment. However, such security

Encryption Support

mechanisms do not apply to WLANs because the walls containing the network do not necessarily bind radio waves. WEP seeks to establish protection similar to that offered by the wired network’s physical security measures by encrypting data transmitted over the WLAN. Data encryption protects the vulnerable wireless link between clients and access points. Once this measure has been taken, other typical LAN security mechanisms such as authentication, password protection, and end-to-end encryption, can be put in place to protect privacy.

With the WEP protocol, all access points and client radio NICs on a particular wireless LAN must use the same encryption key. Each sending station encrypts the body of each frame with a WEP key before transmission, and the receiving station decrypts it using an identical key. This process reduces the risk of someone passively monitoring the transmission and gaining access to the information contained within the frames.

The WEP implementation allows the Security Profile configuration to specify one of four possible WEP keys that can be configured by a user station key management program.