Radsecproxy

Die Föderationsanbindung der lokalen Einrichtungen an die globale eduroam-Infrastruktur geschieht über die Föderationsproxies des Deutschen Forschungsnetzes. Hierfür wird RADIUS over TLS ( RFC6614 ) genutzt.

Als Software empfehlen wir radsecproxy. Die Software kann aus den Paketquellen installiert (z.B. bei Debian über apt install radsecproxy) oder selbst kompiliert werden. Anleitungen zum selbst kompilieren finden sich auf der Seite von radsecproxy.

Die Konfiguration geschieht dann über die Datei /etc/radsecproxy.conf

Wir haben eine Beispielkonfiguration mit den wichtigsten Elementen, die einzelnen Konfigurationsblöcke sind im Folgenden auf dieser Seite beschrieben.

Die Verbindung zum Föderationsproxy wird über TLS abgesichert. Hierfür benötigt Radsecproxy ein Zertifikat, ebenso müssen die Zertifikate der Gegenstelle überprüft werden. Da radsecproxy in der Regel unter dem User-Account radsecproxy läuft, empfiehlt es sich, einen neuen Ordner /etc/radsecproxy anzulegen, auf dem der radsecproxy-User entsprechende Leserechte besitzt.

Der DFN-Verein betreibt eine Special-Purpose-CA für die Anbindung der lokalen Radsecproxies an die Föderationsinfrastruktur. Die Beantragung von Zertifikaten dieser CA ist hier beschrieben.

Für die korrekte Funktionsweise muss das CA-Zertifikat in den entsprechenden Ordner heruntergeladen werden ( https://pki.pca.dfn.de/eduroam-ca/pub/cacert/chain.txt ).

$> wget -O /etc/radsecproxy/eduroam-ca.pem https://pki.pca.dfn.de/eduroam-ca/pub/cacert/chain.txt

Der TLS-Block in der radsecproxy.conf kann dann wie folgt aussehen:

tls default {
    CACertificateFile   /etc/radsecproxy/eduroam-ca.pem
    CertificateFile     /etc/radsecproxy/ihr-eduroam-ca-zertifikat.pem
    CertificateKeyFile  /etc/radsecproxy/ihr-eduroam-ca-private-key.pem
}

Zertifikate der DFN-PKI müssen mit dem Profil “RADIUS-Server” erstellt werden, Nur dann haben sie die benötigten Zertifikatsattribute. Die Zertifikate müssen über den PKI-Zugang Ihrer Einrichtung beantragt und genehmigt werden.

Wird ein DFN-PKI-Zertifikat für die Authentifizierung genutzt, muss auch das Server-Zertifikat von den Föderationsservern gegen die DFN-PKI (bzw. gegen das Root-Zertifikat von TeleSec) geprüft werden. Dazu kann der TLS-Block in der radsecproxy.conf so aussehen:

tls default {
    CACertificateFile   /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem
    CertificateFile     /etc/radsecproxy/ihr-dfn-pki-zertifikat.pem
    CertificateKeyFile  /etc/radsecproxy/ihr-dfn-pki-private-key.pem
}

Der DFN betreibt 3 Föderationsserver mit folgenden Details:

Die DNS-Namen lösen dabei nur auf die IPv4-Adresse auf.

Eine einfache Konfiguration definiert nun die folgenden Server- und Client-Blöcke: (Bei einfachen Service-Provider-Konfigurationen können die Client-Blöcke weggelassen werden.

client tld1.eduroam.de {
    type tls
}
client tld2.eduroam.de {
    type tls
}
client tld3.eduroam.de {
    type tls
}
server tld1.eduroam.de {
    type tls
    StatusServer on
}
server tld2.eduroam.de {
    type tls
    StatusServer on
}
server tld3.eduroam.de {
    type tls
    StatusServer on
}

Um die IP-Adresse festzuschreiben und dadurch nicht von DNS abhängig zu sein kann eine alternative Konfiguration genutzt werden. Diese muss genutzt werden, wenn die Anbindung an die Föderationsproxies über IPv6 geschehen soll. Hierbei muss allerdings die Überprüfung des Zertifikatsnamens manuell angepasst werden:

client tld1.eduroam.de {
    host 193.174.75.134
    # alternativ bei IPv6
    #host 2001:638:d:c105::134
    type tls
    CertificateNameCheck Off
    MatchCertificateAttribute SubjectAltName:DNS:/^tld1\.eduroam\.de$/
}
client tld2.eduroam.de {
    host 193.174.75.138
    # alternativ bei IPv6
    #host 2001:638:d:c106::138
    type tls
    CertificateNameCheck Off
    MatchCertificateAttribute SubjectAltName:DNS:/^tld2\.eduroam\.de$/
}
client tld3.eduroam.de {
    host 194.95.245.98
    # alternativ bei IPv6
    #host 2001:638:d:c104::98
    type tls
    CertificateNameCheck Off
    MatchCertificateAttribute SubjectAltName:DNS:/^tld3\.eduroam\.de$/
}
server tld1.eduroam.de {
    host 193.174.75.134
    # alternativ bei IPv6
    #host 2001:638:d:c105::134
    type tls
    StatusServer on
    CertificateNameCheck Off
    MatchCertificateAttribute SubjectAltName:DNS:/^tld1\.eduroam\.de$/
}
server tld2.eduroam.de {
    host 193.174.75.138
    # alternativ bei IPv6
    #host 2001:638:d:c106::138
    type tls
    StatusServer on
    CertificateNameCheck Off
    MatchCertificateAttribute SubjectAltName:DNS:/^tld2\.eduroam\.de$/
}
server tld3.eduroam.de  {
    host 194.95.245.98
    # alternativ bei IPv6
    #host 2001:638:d:c104::98
    type tls
    StatusServer on
    CertificateNameCheck Off
    MatchCertificateAttribute SubjectAltName:DNS:/^tld3\.eduroam\.de$/
}

Die Anbindung der Access Points bzw. WLAN-Controller kann auf zwei verschiedene Arten erfolgen:

Sie können entweder an den RADIUS-Server angebunden werden. In diesem Fall reicht der Radsecproxy die Authentifizierungen einfach nur an den lokalen FreeRADIUS weiter und benötigt zu diesem auch eine Anbindung in beide Richtungen.

Alternativ können die APs/Controller auch direkt an den Radsecproxy angebunden werden. Dieses Setup wird bei reinen SP-Installationen empfohlen, da hier keine Erfordernis für einen RADIUS-Server gibt.

Laufen RADIUS-Server und radsecproxy auf dem selben Server, muss der RADIUS-Port von radsecproxy über die Anweisung ListenUDP <IP-Adresse des Servers>:<UDP-Port> auf einen anderen Port gesetzt werden.

Die Clients können dabei entweder einzeln mit ihrer jeweiligen IP-Adresse oder als ein ganzes Subnetz konfiguriert werden.

client 192.0.2.1 {
    type udp
    secret <shared secret>
}
client 198.51.100.0/24 {
    type udp
    secret <shared secret>
}

Der eigene RADIUS-Server kann über einen Server-Block an den Radsecproxy angebunden werden:

server ihr-radius-server {
    type udp
    host 203.0.113.1
    secret <shared secret>
}

Haben Sie mehrere RADIUS-Server, müssen Sie entsprechend mehrere Server-Blöcke anlegen.

server ihr-radius-server-1 {
    type udp
    host 203.0.113.1
    secret <shared secret>
}
server ihr-radius-server-2 {
    type udp
    host 203.0.113.2
    secret <shared secret>
}

Das Routing der verschiedenen Realms geschieht über realm-Blöcke. Hier wird für jede Realm definiert, welcher Server zuständig ist. Die angegeben Namen entsprechen hierbei den angegebenen Namen der server-Blöcke. Existieren mehrere RADIUS-Server, können im Realm-Block mehrere angegeben werden. Radsecproxy wird sie in der angegebenen Reihenfolge durchprobieren. Die Redundanz ist hier nach Hot-Standby (der nächste Server wird erst genutzt, wenn der vorherige ausfällt) und nicht im Round-Robin oder Load-Balancing.

Um die Last auf den Föderationsserver des DFN zu verringern, sollten verbreitete Fehler in der Realm-Konfiguration bereits auf dem lokalen Radsecproxy abgefangen werden. Dazu gehören z.B. Leerzeichen im Realm (z.B. am Ende, wenn Autocomplete genutzt wurde) oder 3GPP-Realms, die für SIM-Authentifizierungen im Mobilfunknetz genutzt werden. Da Radsecproxy die Realms sequenziell nach der Reihenfolge in der Konfiguration durchgeht, muss dieser Block entsprechend vor der Default-Regel stehen.

realm ihre-realm.de {
    server ihr-radius-server-1
    server ihr-radius-server-2
}

# Abfangen von typischen Fehlkonfigurationen in Clients
# (Vor dem Default-Block, da sonst die Regeln nicht ausgewertet werden.)
realm /\.$/ {
    replymessage "Misconfigured client: Realm must not end with dot."
}
realm /\.3gppnetwork.*/ {
    replymessage "Misconfigured client: 3GPP realm is not usable for eduroam."
}
realm /\s/ {
    replymessage "Misconfigured client: Realm must not contain spaces"
}

# Default-Regel: Alles unbekannte zu den DFN-Servern weiterleiten
# Dieser Block sollte ganz am Ende der Konfiguration stehen
realm * {
    server tld1.eduroam.de
    server tld2.eduroam.de
    server tld3.eduroam.de
}