Project

General

Profile

EAP-Radius

The eap-radius plugin does not implement an EAP method directly, but it redirects the EAP conversation with a client to a RADIUS backend server. On the gateway, the EAP packets get extracted from the IKE messages and encapsulated into the RADIUS protocol, and vice versa. The gateway itself does not need special support for a specific EAP method, as it handles the EAP conversation between the client and the RADIUS backend more or less transparently.

RADIUS servers

The plugin should work with any RADIUS server, we tested it successfully with FreeRADIUS and the NPS Server included with Windows Server 2008 R2.

For EAP methods providing an MSK, the RADIUS server must include the key within the MPPE-Send/Receive Keys; Unfortunately, FreeRADIUS before 2.1.10 did not include these attributes when used with EAP-MSCHAPv2.

Installation

To compile strongSwan with the eap-radius plugin, add

--enable-eap-radius
to the ./configure options.

Configuration

To let a connection definition in ipsec.conf use the RADIUS backend server, define

  rightauth=eap-radius

in the corresponding section (assuming right is remote).

Configuration for the RADIUS plugin itself is done in strongswan.conf, in the section

charon {
  plugins {
    eap-radius {
       ...
    }
  }

Basic configuration

Starting with version 4.4.1, the plugin supports multiple servers. The configuration format has slightly changed (but the old format is still supported).

To define a RADIUS backend server, add a new section to the servers subsection with a name of your choice:

servers {
  server-a {
    address = 1.2.3.4
    secret = R4diu5-shared-$ecreŧ
    # nas_identifier = ipsec-gateway
  }
}

The address parameter specifies the RADIUS server IP address or DNS name. The secret is used to authenticate the packets exchanged with the RADIUS server.

In untrusted networks, make sure to use a strong secret with enough entropy. This secret might be subject to dictionary attacks.

The nas_identifer (default: strongSwan) identifies the gateway against the RADIUS server and allows it to enforce a policy, for example. If you need an UDP port different from the RADIUS default (1812), use the port option.

Accounting

Starting with release 4.6.2, strongSwan supports RADIUS accounting. It is disabled by default and can be enabled using the accounting option. A non-standard port can be specified using the acct_port option in the server section. The new auth_port option is an alias for the port option.

accounting = yes
servers {
  server-a {
    address = 1.2.3.4
    auth_port = 1812   # default
    acct_port = 1813   # default
  }
}

strongSwan sends Start and Stop Accounting requests, support for interim updates was added with 5.0.3. The Start message contains the Username and Framed-IP attributes (since 5.0.3 also NAS-Port, NAS-IP and Calling/Called-Station-ID), the Stop message additionally Session-Time, Input-Octets and Output-Octets (and since 5.0.3 also Input-Packets and Output-Packets). Gigaword attributes are sent if required.

Since 5.6.1 the plugin optionally adds Class attributes received in Access-Accept messages to RADIUS accounting messages.

XAuth

strongSwan release 5.1.0 introduces an XAuth backend in the eap-radius plugin to directly verify XAuth credentials using RADIUS User-Name and User-Password attributes. The same set of servers is used for both EAP and XAuth authentication, and Accounting and other RADIUS functionality can be used with XAuth as well.

To configure a connection to verify XAuth credentials with RADIUS, set rightauth2 (or rightauth for Hybrid mode) to xauth-radius.

Multiple rounds

Introduced with strongSwan release 5.1.1, the eap-radius backend supports multiple XAuth rounds. It initiates multiple XAuth exchanges, for each the client shows a dialog with an appropriate message. All replies get concatenated to the User-Password attribute, which gets verified over RADIUS.

The number and kind of rounds is configured by so called authentication profiles. You can have multiple profiles defined, each in its own subsection of the eap-radius.xauth section:

eap-radius {
  # ...
  xauth {
    pinprofile {
      nextpin = Please enter the next Code from your scratch list:
    }
    passandcode {
      password = Please enter your Password:
      passcode = Please enter current authenticator token code:
    }
    passandcodegerman {
      password = Bitte Passwort eingeben:
      passcode = Bitte aktuellen Code des Tokens eingeben:
    }
  }
}

This example defines three XAuth profiles, the pinprofile just asking for a PIN, the passandcode profile asking for both a password and a passcode, and the passandcodegerman doing the same in German language. In the latter two, the two answers just get concatenated, and it is up to the AAA to correctly verify this answer.

Valid XAuth types to request are: password, passcode, nextpin and answer. For strongSwan or the AAA these types are not relevant, but the client may show different dialog types (along with the configured message).

To use the configured profiles, you'll have to refer to them in the ipsec.conf connection. To do so, append the profile name, separated by a colon, to the xauth-radius XAuth backend configuration in rightauth or rightauth2:

conn finance
   # Certificate authentication + PIN:
   rightauth=pubkey
   rightauth2=xauth-radius:pinprofile
   # ...

conn sales
   rightid=sales@example.com
   # Hybrid authentication with password+passcode
   rightauth=xauth-radius:passandcode
   # ...

conn sales-german
   rightid=sales.german@example.com
   rightauth=xauth-radius:passandcodegerman
   # ...

The native iOS and OS X clients are known to work fine with multiple authentication rounds.

Session-Timeout and Dynamic Authorization Extension

Release 4.6.3 introduces support for the RADIUS Session-Timeout attribute and the Dynamic Authorization extension, RFC 5176.

A received Session-Timeout from the RADIUS backend is enforced using Repeated Authentication, RFC 4478.

The Dynamic Authorization Extension allows a RADIUS backend to actively terminate a session using a Disconnect-Request, or change the timeout of a session using a Session-Timeout attribute in a CoA-Request. The extension is enabled using a dae section in the eap-radius configuration:

dae {
  enable = yes      # enable DAE extension
  listen = 0.0.0.0  # listen address, default to all
  port = 3799       # port to listen for requests, default
  secret = xxx      # shared secret to verify/sign DAE messages
}

RADIUS attribute forwarding

The following RADIUS attributes are forwarded in corresponding configuration attributes (more details about the attributes can be found in the docs about the attr plugin):

RADIUS attribute Configuration attribute Description
Framed-IP-Address 8 INTERNAL_IP4_ADDRESS 1 Virtual IP address, since 5.0.3.
Framed-IP-Netmask 9 INTERNAL_IP4_NETMASK 2 Netmask of the internal network, since 5.1.1.
Framed-IPv6-Address 168 INTERNAL_IP6_ADDRESS 8 Virtual IP address, since 5.3.3.
DNS-Server-IPv6-Address 169 INTERNAL_IP6_DNS 10 DNS server, since 5.3.3.
Microsoft DNS/NBNS servers (defined in Microsoft's PEN: 0x000137)
MS-Primary-DNS-Server 28 INTERNAL_IP4_DNS 3 DNS server, since 5.2.1.
MS-Secondary-DNS-Server 29
MS-Primary-NBNS-Server 30 INTERNAL_IP4_NBNS 4 NBNS server, since 5.2.1.
MS-Secondary-NBNS-Server 31
Cisco DNS/NBNS servers (defined in Altiga's PEN: 0x000c04)
CVPN3000-Primary-DNS 5 INTERNAL_IP4_DNS 3 DNS server, since 5.2.1.
CVPN3000-Secondary-DNS 6
CVPN3000-Primary-WINS 7 INTERNAL_IP4_NBNS 4 NBNS server, since 5.2.1.
CVPN3000-Secondary-WINS 8
Cisco Unity extensions for IKEv1 (defined in Altiga's PEN: 0x000c04)
CVPN3000-IPSec-Banner1 15 UNITY_BANNER 28672 Message displayed on certain clients after login, since 5.0.3.
CVPN3000-IPSec-Split-Tunnel-List 27 UNITY_SPLIT_INCLUDE 28676 The attribute contains a comma-separated list of subnets that are either included in a UNITY_SPLIT_INCLUDE or a UNITY_LOCAL_LAN attribute, depending on the value of the CVPN3000-IPSec-Split-Tunneling-Policy attribute, since 5.1.1.
UNITY_LOCAL_LAN 28678
CVPN3000-IPSec-Default-Domain 28 UNITY_DEF_DOMAIN 28674 Default search domain, since 5.1.1.
CVPN3000-IPSec-Split-DNS-Names 29 UNITY_SPLITDNS_NAME 28674 Space-separated list of domain names, since 5.1.1.
CVPN3000-IPSec-Banner2 36 Same as CVPN3000-IPSec-Banner1.
CVPN3000-IPSec-Split-Tunneling-Policy 55 Determines what kind of attributes is used for the subnets in the CVPN3000-IPSec-Split-Tunnel-List attribute. The value 1 corresponds to UNITY_SPLIT_INCLUDE, and the value 2 to UNITY_LOCAL_LAN, since 5.1.1.

Arbitrary RADIUS attribute forwarding

Starting from version 4.6.3, arbitrary RADIUS attributes can be forwarded from/to the IKE peer using custom IKEv2 notify payloads. The notify uses the strongSwan specific private notify 40969. Forwarding is configured in a eap-radius subsection called forward:

forward {
  ike_to_radius = Reply-Message, 11
  radius_to_ike = 36906:12
}

Both options define a comma separated list of RADIUS attributes to forward in each direction. Attributes can be defined by name or attribute number. The number in front of a colon defines a Vendor-Specific attribute to forward.

An IKE peer can use the radattr plugin to provide/print such attributes.

Parallel RADIUS sessions

The EAP exchange over RADIUS might need several packets, and depending on the RTT, several fractions of a second. As a single RADIUS client port can handle only one concurrent authentication session, multiple client ports can be used to do parallel authentication for high load scenarios.

The per-server sockets option (default: 1) defines the number of pre-allocated sockets to use. A value of 5 allows the gateway to authentication 5 clients simultaneously over RADIUS.

Multiple servers

Multiple RADIUS servers can be defined for high availability or load sharing purposes. Use additional sections in the servers subsection and configure them accordingly.

The used server for an authentication session is selected randomly. If a server is under load (that is, one or more of the defined sockets are in use), the server is degraded in the election process. If a server is unreachable, it is further degraded. From time to time, a previously non-responsive server is reused to automatically reintegrate it if it becomes available again.

Preferring servers

With the preference paramter of a server, priorities for specific servers can be defined. This allows to use a secondary RADIUS server only if the first gets unresponsive, or if it is overloaded.

A reachable server gets a priority value between 110 and 210, proportionally to the current use of its sockets (higher is better). Previously unavailable servers get a value of 0-100, only. The defined preference value is added to the calculated priority. Servers with the same calculated value will be elected randomly. The following preference values result in:

  • 0: Default, fair selection based on server load
  • 1: Prefer the server, as long as it is completely unloaded
  • 50: Prefer the server, unless more than half of the sockets are in use
  • 99: Always prefer the server, unless no sockets are currently available
  • 101: Always prefer the server, unless it gets unreachable

Defining a preference of 110 and more is probably not a good idea, as such a server will win the election process, even if it is not available.

Identity exchange

The plugin starts the conversation with the RADIUS server directly with an EAP-Identity response using the IKEv2 identity of the peer.

To enforce a different identity in this exchange, set

  eap_identity=test@example.com

in an ipsec.conf section.

To do an EAP-Identity exchange with the client and ask for an EAP-Identity, set

  eap_identity=%identity

Another option is to let the RADIUS server itself initiate the EAP conversation by sending an EAP-Start message. Set eap_start = yes in the eap-radius section of strongswan.conf to initiate the conversation with EAP-Start. This kind of operation is not supported by all RADIUS servers. Don't forget --enable-eap-identity if you use EAP-Identity exchanges initiated by the gateway.

The id_prefix option in the same section prepends a prefix to the negotiated identity. This is useful, as some RADIUS servers interpret such a prefix as a request for a specific EAP method (e.g. 0 as EAP-SIM, 1 as EAP-AKA).

Group selection

The plugin optionally interprets the class attribute sent in the RADIUS-Accept message as group membership information. An ipsec.conf configuration with

  rightgroups="sales@strongswan.org, finance@strongswan.org" 

is acceptable only if the RADIUS server includes one of the two groups in the class attribute. As this behavior is not standardized, the boolean flag class_group in the eap-radius plugin subsection must be set to yes.

Example configuration

ipsec.conf

# ....

# sales and finance have access to some servers only
conn sales-finance
  # ...
  leftsubnet=10.0.1.2/32,10.0.4.5/32
  # require groups specified as Distinguished Name. As the groups are
  # specified with commas, separate the RDNs with slashes.
  rightgroups="O=strongswan/OU=sales,O=strongswan/OU=finance" 
  rightauth=eap-radius
  # request EAP-Identity
  eap_identity=%identity
  auto=add

# research has access to testing lab
conn research
  # ...
  leftsubnet=10.0.2.0/24
  rightgroups="O=strongswan/OU=research" 
  rightauth=eap-radius
  eap_identity=%identity
  auto=add

strongswan.conf


charon {
  plugins {
    eap-radius {
      class_group = yes
      eap_start = no
      servers {
        primary {
          address = radius1.strongswan.org
          secret = $ecreŧxyz
          nas_identifer = ipsec-gateway
          sockets = 20
          # use secondary only if overloaded/non-responsive
          preference = 99
        }
        secondary {
          address = radius2.strongswan.org
          secret = $ecreŧabc
          nas_identifer = ipsec-gateway
          sockets = 5
          # uses custom RADIUS authentication port
          port = 12345
        }
      }
    }
  }
}