Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:eduroam:admins:faq [2018/02/19 14:58] – [Welches Zertifikat kommt in welche Datei?] Steffen Klemer
+++ de:eduroam:admins:faq [2018/03/15 14:23] – Steffen Klemer
@@ Zeile 12: / Zeile 12: @@
 **Hintergrund:**
-Die Kommunikation der TLD/Backbone-eduroam-Server erfolgt ebenfalls via RADSEC-Protokoll. Der Vertrauens-Anker hierbei ist ein Ast der sogenannten [[https://www.edupki.org/|eduPKI]]. Das ist der Ursprung dieses Zertifikats. Nun bleibt die Frage, warum wir dies als Default tragen und nicht das der DFN PKI: Für die Länder-Domains wie .se, .de, .fr etc. ist das Routing im Backbone sehr einfach und strikt hierarchisch lösbar -- alles geht zum jeweiligen NREN. Wohin aber mit .eu? Und warum überhaupt so unflexibel statisch? Als Lösung gibt es die so-genannten [[https://wiki.geant.org/display/H2eduroam/DNS-NAPTR|NAPRT-Einträge im DNS für eduroam]], die besagen, wie der Heimat-eduroam-Server dieses Realms heißt. Damit kann nun aber plötzlich jeder eduroam Backbone-Server die DFN-Server mit berechtigtem Interesse kontaktieren und es muss immer zuerst das eduPKI-Zertifikat gezeigt werden. Und leider sieht TLS keinen //Blumenstrauß// für eine Zertifikatsauswahl vor, weshalb nur der harte Weg einer händischen Konfiguration der DFN-PKI-sprechenden Server bleibt.
+Die Kommunikation der TLD/Backbone-eduroam-Server erfolgt ebenfalls via RadSec-Protokoll. Der Vertrauens-Anker hierbei ist ein Ast der sogenannten [[https://www.edupki.org/|eduPKI]]. Das ist der Ursprung dieses Zertifikats. Nun bleibt die Frage, warum wir dies als Default tragen und nicht das der DFN PKI: Für die Länder-Domains wie .se, .de, .fr etc. ist das Routing im Backbone sehr einfach und strikt hierarchisch lösbar -- alles geht zum jeweiligen NREN. Wohin aber mit .eu? Und warum überhaupt so unflexibel statisch? Als Lösung gibt es die so-genannten [[https://wiki.geant.org/display/H2eduroam/DNS-NAPTR|NAPRT-Einträge im DNS für eduroam]], die besagen, wie der Heimat-eduroam-Server dieses Realms heißt. Damit kann nun aber plötzlich jeder eduroam Backbone-Server die DFN-Server mit berechtigtem Interesse kontaktieren und es muss immer zuerst das eduPKI-Zertifikat gezeigt werden. Und leider sieht TLS keinen //Blumenstrauß// für eine Zertifikatsauswahl vor, weshalb nur der harte Weg einer händischen Konfiguration der DFN-PKI-sprechenden Server bleibt.
 Heimateinrichtungen sind nicht berechtigt, eduroam-Backbone-fähige Zertifikate der eduPKI zu bekommen. Dies ist auch nicht notwendig.
+===== Es ist ein Sicherheitsvorfall geschehen, wen kontaktiere ich? =====
-===== Wie heißen die DFN radsec Server und was für ein Zertifikat haben sie? =====
+Bitte kontaktieren Sie die [[https://www.dfn.de/kontakt/|DFN eduroam-Admins]].
-  * tld1.eduroam.de: 193.174.75.134, Regulärer Ausdruck für den CN: ''/^(radius1\.dfn|tld1\.eduroam)\.de$/''
-  * tld2.eduroam.de: 193.174.75.138, Regulärer Ausdruck für den CN: ''/^(radius2\.dfn|tld2\.eduroam)\.de$/''
+===== Wie heißen die DFN RadSec Server und was für ein Zertifikat haben sie? =====
-  * Die Zertifikate beider Server wurden signiert durch die **neue ODER alte DFN PKI**. Momentan (Feb 2018) //müssen// Teilnehmer der .de eduroam Föderation //beide PKIs unterstützen//. Die Signatur ist von ''/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Certification Authority 2'' ODER ''/C=DE/O=DFN-Verein/OU=Geschaeftsstelle/CN=DFN-Verein-GS-CA - G02'' .
+vgl. [[de:eduroam:admins:basics|Basis-Daten]].
 ===== Welches Zertifikat kommt in welche Datei? =====
-Für openssl-basierte Programme (radsecproxy, freeradius, ...) hat sich unten stehende Aufteilung sowohl im PEAP/TTLS, als auch radsec-Fall bewährt. Die Zertifikate / Schlüssel müssen im ''.pem''-Format vorliegen. Es ist problemlos möglich, den Inhalt verschiedener ''.pem''-Dateien //mittels Text-Editor hintereinander zu kopieren//. Möglichkeiten der Konvertierung aus anderen Formaten finden sich auf https://www.sslshopper.com/article-most-common-openssl-commands.html .
+Für openssl-basierte Programme (radsecproxy, freeradius, ...) hat sich unten stehende Aufteilung sowohl im PEAP/TTLS, als auch RadSec-Fall bewährt. Die Zertifikate / Schlüssel müssen im ''.pem''-Format vorliegen. Es ist problemlos möglich, den Inhalt verschiedener ''.pem''-Dateien //mittels Text-Editor hintereinander zu kopieren//. Möglichkeiten der Konvertierung aus anderen Formaten finden sich auf https://www.sslshopper.com/article-most-common-openssl-commands.html .
   * **Server Certificate**
@@ Zeile 34: / Zeile 36: @@
       *  Erstes Intermediate (meist ''/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Global Issuing CA'')
       *  Zweites Intermediate (meist ''/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Certification Authority 2'')
-    * Für radsec muss das Server-Zertifikat außerdem die //Client-Eigenschaft// haben. Das erreicht man in der DFN-PKI zB dadurch, dass beim Antrag bei //Typ// Radius-Server statts des voreingestellten 'Webserver' ausgewählt wird.
+    * Für RadSec muss das Server-Zertifikat außerdem die //Client-Eigenschaft// haben. Das erreicht man in der DFN-PKI zB dadurch, dass beim Antrag bei //Typ// Radius-Server statts des voreingestellten 'Webserver' ausgewählt wird.
     * Enthält //nicht das root-Zertifikat//! Das war immer ein Implementierungsfehler auf Clientseite, ist aber im Jahr 2018 auch überall behoben. Sparen Sie Ihren Clients 2 EAP-Round-Trips!.
   * **Certificate Key**
     * enthält den Server-Key
   * **CA Certificate**
-    * Nur für radsec zum DFN (und EAP-TLS, nicht PEAP/TTLS) relevant
+    * Nur für RadSec zum DFN (und EAP-TLS, nicht PEAP/TTLS) relevant
     * Enthaelt beide(!) Telekom-Zertifikate:
       * ''/C=DE/O=T-Systems Enterprise Services GmbH/OU=T-Systems Trust Center/CN=T-TeleSec GlobalRoot Class 2''
@@ Zeile 45: / Zeile 47: @@
 Die beschrieben Zertifikate der beteiligten CAs erhalten sie [[https://www.pki.dfn.de/wurzelzertifikate/globalroot2/|hier]] und [[https://www.pki.dfn.de/wurzelzertifikate/globalroot/|hier]].
+===== Ich will mein RadSec-Zertifikat ändern, was muss ich beachten? =====
+So lange sich weder IP-Adresse noch CN im Zertifikat des mit dem DFN sprechenden Servers ändern, brauchen Sie nichts zu beachten und müssen dies auch nirgendwo melden. Beachten Sie, dass nur Zertifikate der alten oder neuen DFN PKI zugelassen sind.
+===== Ich will irgendwas an meinem RADIUS-Server ändern, was muss ich beachten? =====
+So lange sich weder IP-Adresse noch CN im Zertifikat des mit dem DFN sprechenden Servers ändern, brauchen Sie nichts zu beachten und müssen dies auch nirgendwo melden. In allen anderen Fällen [[https://www.dfn.de/kontakt/|kontaktieren Sie bitte den DFN]].
+Beachten Sie, dass die DFN eduroam-Server //keinerlei DNS-Informationen auswerten//; weder eine Vorwärtsauflösung beim IP-Verbindungsaufbau noch eine Rückwärtsauflösung beim Zertifikats-Check.
+===== Kann ich das selbe Zertifikat auf mehreren Servern einsetzen? =====
+//Das hängt davon ab.// Zunächst müssen die beiden Anwendungsfälle für Zertifikate im eduroam-Umfeld unterschieden werden:
+**PEAP/EAP-TTLS/EAP-TLS** Diese Zertifikate werden verwendet bei der Client-zu-Heimat-Einrichtung Kommunikation; also den möglichst sicheren Tunnel zwischen WLAN-Endgerät und RADIUS-Server durch den die User-Credentials laufen. Da keine IP-Kommunikation vorliegt, kann der Client das Zertifikat nicht anhand der IP/DNS-Namen überprüfen und ist auf einen fest konfigurierten Check eines der Attribute des Server-Zertifikats angewiesen. Zumeist wird dies der CN oder altName sein. Nicht alle Betriebssystem sehen hier eine Wild-Card oder regulären Ausdruck vor, weshalb die Zertifikate auf ggf. mehreren redundanten Server den selben Eintrag im entsprechenden Feld aufweisen sollten. Einige Betriebssysteme sehen zudem eine Art Zertifikats-Pinning vor, das aus dem Tritt kommt, wenn aufgrund einer Redundanzumschaltung nun vom anderen Server eine anderes Zertifikat gezeigt wird. Ob dies der Fall ist oder nicht, hängt vom Betriebssystem, der Versionsnummer und einigen Konfigurationsparametern ab. Einige Systeme haben in der Vergangenheit auch (mehrfach) ihr Verhalten diesbezüglich geändert. Daher ist die Empfehlung bei mehreren RADIUS-Server, **für die PEAP/TTLS/TLS-Verbindung die selben Zertifikate auf allen Servern** einzusetzen.
+**RadSec** Diese Zertifikate werden verwendet bei der Einrichtung-zu-DFN Server-Kommunikation im Backbone. Da im Server-Umfeld davon ausgegangen werden kann, dass die Zertifikats-Checks korrekt implementiert sind, ist der Tausch von Zertifikaten ('Zertifikats-Roll-Over') relativ einfach (vgl. die Frage zuvor). Die geschützten Informationen sind von mittlerer Wichtigkeit (pseudonyme Bewegungsdaten aber keine Passwörter und zumeist keine Identitäten). Es gibt keine zwingenden Gründe für verschiedene Zertifikate pro Server, aber auch wenig operative Gründe, die dagegen sprechen. Verschiedene Zertifikate bieten natürlich etwas mehr Sicherheit, sollte eines 'verlorengehen'.
+Man könnte für die EAP-Tunnel und die RadSec-Verbindung auch die selben Zertifikate einsetzen. Wenn beide Dienste auf dem selben Server laufen, vereinfacht es ggf. auch die operativen Prozesse. Wenn man von Lücken in TLS-Implementierungen absieht, ist das größte potentielle Problem sicher ein gehackter Server. Wer hier nicht sehr gewissenhaft mit den Dateisystemrechten war oder die Einbrecherin schon root-Rechte hat, hat eh beide Zertifikate "verloren". Im Sinne des KISS-Prinzips ist es in diesem Fall vermutlich zu rechtfertigen, sogar für diese beiden grundverschiedenen Anwendungsfälle das selbe Zertifikat zu verwenden. Die sicherere Variante ist es, 2 verschiedene einzusetzen.
+===== Warum wird mit festen IP-Adressen gearbeitet? =====
+In der Vergangenheit gab es zu oft Probleme mit nicht auflösenden DNS-Namen, die aus technischen Gründen die Server-Software und damit den eduroam-Dienst in Deutschland als ganzes beeinträchtigt haben.
+===== Kann mein RadSec-Server hinter einer Firewall stehen? =====
+Ja, definitiv!
+  * RadSec-Server von SP müssen einzig ausgehend Verbindungen zu den DFN-Servern TCP-Ziel-Port 2083 aufbauen. Wenn es sich nicht vermeiden lässt, funktioniert es technisch sogar durch ein n:m NAT hindurch.
+  * RadSec-Server von IdP müssen zusätzlich eingehende Verbindungen von den DFN-Servern auf TCP-Ziel-Port 2083 erlauben.
+  * Die IPs der DFN-Server sind [[de:eduroam:admins:basics|auf der allgemeinen Info-Seite]] dokumentiert.
+===== Wird IPv6 unterstützt? =====
+Die DFN eduroam-Server unterstützen im Moment keine RadSec-Verbindungen via IPv6. Es ist aber geplant.
+===== Darf ich die eduroam-Infrastruktur für etwas anders als Netzwerkzugang einsetzen? =====
+Nein.