Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

RADIUS/TLS: Using radsecproxy as an add-on

...

to

...

an

...

existing

...

RADIUS

...

server

Goals and Prerequisites

This section describes a trimmed-down

...

installation

...

of

...

radsecproxy

...

which

...

enables

...

it

...

to

...

augment

...

any

...

RADIUS

...

server

...

with

...

RADIUS/TLS

...

transport, in order to enhance security.

...

More

...

precisely,

...

with

...

this

...

setup

...

radsecproxy

...

will:

...

  • Accept

...

  • requests

...

  • from

...

  • a

...

  • RADIUS

...

  • server

...

  • running

...

  • on

...

  • the

...

  • same

...

  • host

...

  • Unconditionally

...

  • forward

...

  • the

...

  • requests

...

  • via

...

  • RADIUS/TLS

...

  • to

...

  • an

...

  • upstream

...

  • server

...

  • (typically

...

  • a

...

  • federation-level

...

  • or

...

  • a

...

  • regional

...

  • proxy

...

  • server)

...

  • Accept

...

  • requests

...

  • via

...

  • RADIUS/TLS

...

  • from

...

  • the

...

  • upstream

...

  • server

...

  • Unconditionally

...

  • forward

...

  • these

...

  • requests

...

  • to

...

  • a

...

  • RADIUS

...

  • server

...

  • running

...

  • on

...

  • the

...

  • same

...

  • host

...

The

...

prerequisites

...

for

...

this

...

deployment

...

are:

...

  • radsecproxy

...

  • version

...

  • 1.4.2

...

  • or

...

  • higher

...

  • The

...

  • local

...

  • RADIUS

...

  • server's

...

  • DEFAULT

...

  • realm

...

  • is

...

  • configured

...

  • to

...

  • forward

...

  • requests

...

  • to

...

  • the

...

  • radsecproxy

...

  • port

...

  • on

...

  • localhost.

...

  • The

...

  • local

...

  • RADIUS

...

  • server

...

  • has

...

  • configured

...

  • localhost

...

  • as

...

  • a

...

  • client

...

  • (this

...

  • is

...

  • typically

...

  • the

...

  • case).

...

  • The

...

  • deployment

...

  • requires

...

  • a

...

  • server

...

  • certificate

...

  • and

...

  • a

...

  • private

...

  • key

...

  • for

...

  • that

...

  • certificate

...

  • to

...

  • establish

...

  • the

...

  • RadSec

...

  • connection

...

  • which

...

  • designates

...

  • the

...

  • server

...

  • as

...

  • an

...

  • eduroam

...

  • SP

...

  • and

...

  • IdP.

...

  • For

...

  • further

...

  • information

...

  • regarding

...

  • eduroam

...

  • certificates

...

  • see

...

...

Include Page
radsecproxy-installation
radsecproxy-installation

Sample configuration

Most of the radsecproxy configuration file is static. This section goes through the template radsecproxy.conf line by line and explains the meaning of each stanza.

Code Block

ListenUDP                     localhost:11812
ListenTCP                     *:2083

Since there is a RADIUS server on the same host that occupies UDP/1812, radscproxy has to listen on a nonstandard port. It only needs to listen on the loopback device since it will only communicate with the RADIUS server on the same machine. The choice of 11812 is arbitrary and can be adapted if that port is in use. Since radsecproxy will also accept requests from an upstream RadSec-enabled server, it listens on the default TCP port for RadSec (2083) for requests from outside (the * meaning: all interfaces). If you want radsecproxy to listen only on specific interfaces, enter the interface names here. Beware: in this case you may also have to set the more exotic option SourceTCP (see the man page of radsecproxy for details).

Include Page
radsecproxy-general-settings
radsecproxy-general-settings

Client definition and request forwarding

To accept requests from the RADIUS server on localhost, this server needs to be listed as a client. That server may either use IPv4 or IPv6 for its communication, so both variants are defined. If your system is not IPv6-enabled, simply delete the stanza about client ::1. The _LOCAL_SECRET_ must match the secret which you configured in your RADIUS server for the server catering the DEFAULT realm.

Code Block

client localhost {
        host        127.0.0.1
        type        udp
        secret      __LOCAL_SECRET__
}

client ::1 {
        type        udp
        secret      __LOCAL_SECRET__
}

To accept requests from the upstream RADIUS/TLS-enabled server, this other server needs to be listed. Replace _RADSEC_PEER_ with the hostname of your upstream server. The traditional RADIUS shared secret has no meaning in RADIUS/TLS, and must instead be statically set to "radsec" throughout eduroam. This has no security implications.

Code Block

client _RADSEC_PEER_ {
        type        TLS
        secret     radsec
}

To deliver requests to the local RADIUS server, this server needs to be configured. See above for the
parameter _LOCAL_SECRET_.

Code Block

server localhost {
        type         UDP
        port         1812
        secret       __LOCAL_SECRET__
}

This server needs to be configured to deliver requests to the upstream RadSec-enabled server. See above for
the configuration item _RADSEC_PEER_.

Code Block

server _RADSEC_PEER_ {
        type         TLS
        secret      radsec
        statusserver on
}

There are some known client-side misconfigurations. If they were not already caught by the local RADIUS server, it does not make sense for the proxy to send these requests up to the eduroam infrastructure. These requests are immediately rejected.

Note: if you need to blacklist an existing realm for some reason, you can follow the myabc.com example, copying and replacing it with the realm to be blacklisted.

Code Block

realm /myabc\.com$/ {
         replymessage "Misconfigured client: default realm of Intel PRO/Wireless supplicant!"
}

realm /^$/ {
          replymessage "Misconfigured client: empty realm!"
}

Requests that are coming in from upstream and are supposed to be handled by the own RADIUS server are listed in _OWN_REALM_. Create multiples of these stanzas if your local server serves more than one realm.

Code Block

realm /_OWN_REALM_$/ {
             server localhost
}

The configuration stanza above will terminate all requests that end in _OWN_REALM_ but which were not caught by previous realm definitions, which prevents a possible loop. This is achieved by having the client name = localhost and the server name = localhost, and LoopPrevention enabled, which checks for this condition.

Finally, all other realms which are not to be authenticated locally are sent to the upstream RADIUS/TLS peer:

Code Block

realm * {
          server    __RADSEC_PEER__
}
|H2eduroam:radsec certificates].

h4. Sample configuration

Most of the radsecproxy configuration file is static. Therefore, a template configuration file is provided at [http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip]. A detailed explanation of this configuration file follows, but if you are unwilling to read it all, the comments should make the configuration file almost self-explanatory and you can start and experiment with it right after the initial installation, which is explained below.

h4. Installation

# On UNIX-like systems, the installation is very simple. The code can be downloaded at
\[http://software.uninett.no/radsecproxy/\]. After unpacking it into its base directory, descend into the unpacked directory and type
_make_

           The code is ISO C and should compile cleanly. It usually does not require a ./configure.

      2.  After compiling, the executable:radsecproxy is located in the base directory. Either run this executable here
           or copy it to a convenient location (e.g. /usr/local/bin) and run it there.
           Execution does not require root rights. It expects its configuration file to be in:

           _/etc/radsecproxy.conf_

      3.  Create the directory _/etc/radsecproxy.d/certs/ca/_. The template configuration file requires this directory to
           contain the accredited CA root certificates and the corresponding Certificate Revocation Lists (CAs) in
           their OpenSSL hash form.
      4.  Currently, two CAs are accredited for eduroam. These two certificates and their CRLs need to be
           copied into this directory. For your convenience, we have prepared a script at
           [http://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip] which you can execute in the
           directory. It will download and hash the appropriate files. In this case you can skip steps 7 and 8.
      5.  If you want to download the files manually, download them from these URLs:

*            [http://sca.edugain.org/cacert/eduGAINCA.pem]
*            [http://sca.edugain.org/cacert/eduGAINSCA.pem]
*            [http://pki.edugain.org/edugainca/crl/cacrl.pem]
*            [https://sca.edugain.org/crl/cacrl.pem]

      6.  After downloading, execute the following command in the /etc/radsecproxy.d/certs/ca/ directory:
           \_c_rehash .\_
           (including the dot) to generate OpenSSL hashes of the downloaded files.
      7.  Make sure that the CRL files are regularly re-downloaded. This can for example be done by executing
           the download script regularly with cron. CRLs have a limited validity time themselves -- not regularly
           refreshing the CRLs will eventually cause certificate validation to fail\!
      8.  Copy the template configuration file into /etc/radsecproxy.conf.
      9.  Fill the lines marked with __STUFF_\_.
    10.  Start radsecproxy and enjoy (for first-time use, starting it with the \--f option is recommended, it will start
           radsecproxy in the foreground and show some verbose startup messages).


h4. Detailed explanation of configuration

This section goes through the template radsecproxy.conf line by line and explains the meaning of each stanza.

_ListenUDP                     localhost:11812_
_ListenTCP                     \*:2083_

Since there is a RADIUS server on the same host that occupies UDP/1812, radscproxy has to listen on a nonstandard
port. It only needs to listen on the loopback device since it will only communicate with the RADIUS
server on the same machine. The choice of 11812 is arbitrary and can be adapted if that port is in use. Since
radsecproxy will also accept requests from an upstream RadSec-enabled server, it listens on the default TCP
port for RadSec (2083) for requests from outside (the * meaning: all interfaces). If you want radsecproxy to
listen only on specific interfaces, enter the interface names here. Beware: in this case you may also have to set
the more exotic option SourceTCP (see the man page of radsecproxy for details).

_LogLevel                        3_
\_LogDestination              [file:///var/log/radsecproxy.log\_|file:///var/log/radsecproxy.log_]





A logging level of 3 is the default and recommended log level. Radsecproxy will then log successful and failed
authentications on one line each. The log destination is a typical POSIX-compliant log location.

_LoopPrevention            On_

This enables a semi-automatic prevention of routing loops for RADIUS connections. If you connect a client {...\]
and a server {...} and give them the same descriptive name, the proxy will prevent proxying.

_tls default {_
_       CACertificatePath               /etc/radsecproxy/certs/ca/_
_       CertificateFile                     /etc/radsecproxy/certs/_{_}CERT_PEM_\_\_
_       CertificateKeyFile              /etc/radsecproxy/certs/_{_}CERT_KEY_\_\_
_       CertificateKeyPassword    \__CERT_PASS_\_\_
_       CRLCheck                        On_
_}_

This section defines which TLS certificates should be used by default. This installation of radsecproxy always
uses the same certificates, so this is the only TLS section. CACertificatePath contains the eduroam-accredited
CA certificates with filenames in the OpenSSL hash form. The parameters below need to be adapted to point to
your server certificate in PEM format, the private key for this certificate and the password for this private key if
needed, respectively. If no password is needed for the private key, you can comment this line (i.e. precede it
with a # sign). The option CRLCheck validates certificates against the Certificate Revocation List (CRL) of the
CAs. It requires a valid CRL in place, or else the certificate validation will fail. Therefore, it is important to
regularly update the CRLs by re-downloading them as described above.

_rewrite defaultclient {_
_       removeAttribute 64_
_       removeAttribute 65_
_      removeAttribute 81_
_}_

This section deletes attributes from RADIUS requests that convey VLAN assignment information. If VLAN
information is sent inadvertently, it can cause a degraded or non-existent service for the end user because they
might be put into the wrong VLAN. If you do have a roaming use for cross-institution VLAN assignment, you
may want to delete this stanza.

_Client localhost {_
_        host 127.0.0.1_
_        type        udp_
_        secret     \__LOCAL_SECRET_\_\_
_}_
_client ::1 {_
_       type        udp_
_       secret     \__LOCAL_SECRET_\_\_
_}_

To accept requests from the RADIUS server on localhost, this server needs to be listed as a client. That server
may either use IPv4 or IPv6 for its communication, so both variants are defined. If your system is not IPv6\-
enabled, simply delete the stanza about client ::1. The __LOCAL_SECRET__ must match the secret which
you configured in your RADIUS server for the server catering the DEFAULT realm.

_client \__RADSEC_PEER__ {\__        type        TLS{_}_        secret     mysecret{_}_}_

To accept requests from the upstream RadSec-enabled server, this other server needs to be listed. Replace
__RADSEC_PEER__ with the hostname of your upstream server. The traditional RADIUS shared secret has
no meaning in RadSec and can be statically set without security implications. In current eduroam deployments,
it is set to mysecret. This may change in the future, but will be announced in due time ahead.

_server localhost {_
_        type         UDP_
_        port         1812_
_       secret       \__LOCAL_SECRET_\_\_
_}_

To deliver requests to the local RADIUS server, this server needs to be configured. See above for the
parameter __LOCAL_SECRET_\_.

_server \__RADSEC_PEER__ {\__        type         TLS{_}_        secret      mysecret{_}_        statusserver on{_}_}_


This server needs to be configured to deliver requests to the upstream RadSec-enabled server. See above for
the configuration item __RADSEC_PEER_\_.

_realm /myabc\.com$ {_
_         replymessage "Misconfigured client: default realm of Intel PRO/Wireless supplicant\!"_
_}_

_realm /\[radsecproxy-addon^@\] {_
_          replymessage "Misconfigured client: empty realm\!"_
_}_



There are some known client-side misconfigurations. If they were not already caught by the local RADIUS
server, it does not make sense for the proxy to send these requests up to the eduroam infrastructure. These
requests are immediately rejected.

Note: if you need to blacklist an existing realm for some reason, you can follow the myabc.com example,
copying and replacing it with the realm to be blacklisted.

_realm /_{_}OWN_REALM{_}_$ {_
_             server localhost_
_}_

Requests that are coming in from upstream and are supposed to be handled by the own RADIUS server are
listed in __OWN_REALM_\_. Create multiples of these stanzas if your local server serves more than one realm.

Within the RADIUS infrastructure, it is possible to misconfigure a server so that eternal loops are created, which
may ultimately lead to a DoS condition. The basic problem is: assume a RADIUS server with its own realm
something.org. Further, assume a user who entered john.doe@sub.something.org. A server that only checks if
the realm is equal to something.org will send this request upstream to the eduroam infrastructure. The
infrastructure will in turn detect that the realm ends in something.org and will send the request back to where it
came from, which closes the loop.

The configuration stanza above will terminate all requests that end in __OWN_REALM__ but which were not
caught by previous realm definitions, which prevents the loop. This is achieved by having the client name =
localhost and the server name = localhost, and LoopPrevention enabled, which checks for this condition.

_realm * {_
_          server    \__RADSEC_PEER_\_\_
_}_


h3. Obtaining RadSec certificates

IdP and SP certificates are issued by the NRO. Please contact your NRO for more information on how to obtain
a certificate.