Transportsicherheit in RADIUS vs. RadSec
Bei der Bereitstellung sicherer Authentifizierung unter Verwendung des Extensible Authentication Protocol (EAP) spielt die Wahl des Transportprotokolls – RADIUS über UDP vs. RADIUS über TLS (RadSec) – eine entscheidende Rolle dafür, wie sicher Metadaten und Protokollelemente über das Netzwerk übertragen werden.
Sowohl RADIUS als auch RadSec können EAP-Nachrichten übertragen, einschließlich solcher, die in gängigen Methoden wie EAP-TLS, PEAP und EAP-TTLS verwendet werden. Während die inneren Abläufe der EAP-Methode gleich bleiben, beeinflusst das Transportprotokoll die Sichtbarkeit, Integrität, Vertraulichkeit von Metadaten und das Betriebsverhalten.
Dieses Dokument vergleicht, wie RADIUS und RadSec den EAP-Transport beeinflussen – mit Fokus auf Verschlüsselung, Verwendung des Shared Secret, Offenlegung von Attributen, Protokollierungsfolgen und Bereitstellungsüberlegungen.
Transportsicherheit: Kernunterschiede
EAP-Methoden wie EAP-TLS, PEAP und EAP-TTLS bieten Authentifizierungsmechanismen zwischen Clients (Supplicants) und Authentifizierungsservern. Diese Methoden verschlüsseln jedoch nicht von sich aus den Transport von Metadaten zwischen Zwischenknoten. Diese Aufgabe fällt dem Transportprotokoll zu:
RADIUS (UDP) überträgt EAP-Nachrichten und RADIUS-Attribute im Klartext.
RadSec (TLS) verschlüsselt das gesamte RADIUS-Paket und sichert alle Attribute und Protokollheader während der Übertragung.
Die folgende Tabelle fasst diese Unterschiede zusammen, die die Vertraulichkeit von Attributen wie Outer Identity, NAS-IP, Calling Station ID und mehr beeinflussen. Während EAP-Methoden Benutzeranmeldeinformationen (z. B. Zertifikate oder Passwörter) verschlüsseln können, bleiben Metadaten über Standard-RADIUS offen, es sei denn, RadSec wird verwendet.
Transport-Layer-Protokoll
UDP (typischerweise)
TLS über TCP
Verschlüsselung
Keine Transportsverschlüsselung
Vollständige Transportsverschlüsselung
Standardport*
UDP 1812
TCP 2083
Anmerkungen
Zustandslos; kann von Firewalls gefiltert werden.
Zustandsbehaftet; etabliert sichere Tunnel.
*Während diese Ports anerkannte Standards sind, können einige Deployments sie aus lokalen Richtlinien- oder Infrastrukturgründen anpassen.
Die Rolle des RADIUS Shared Secret in beiden Protokollen
Das RADIUS Shared Secret wird für Paketintegrität und Legacy-Verschlüsselungsverhalten verwendet. Dies gilt unabhängig davon, ob der Transport Standard-RADIUS oder RadSec ist.
Wesentliche Verwendungen:
Message-Authenticator AVP: Stellt die Paketintegrität mittels HMAC-MD5 sicher.
User-Password AVP (Legacy-Methoden): Verschlüsselt Anmeldeinformationen mit dem Shared Secret.
RadSec-Kompatibilität: Auch bei RadSec wird das Shared Secret zur Kompatibilität mit RADIUS-Semantik und Zwischen-Systemen beibehalten.
Hinweis: Das Shared Secret wird niemals über das Netzwerk übertragen – es wird lokal für HMAC-Operationen und AVP-Validierung verwendet.
Sichtbarkeit von Datenelementen: RADIUS vs. RadSec
Diese Tabelle vergleicht wichtige Datenelemente bei Verwendung von EAP-TLS über RADIUS (UDP) und RadSec (TLS), gruppiert nach Sichtbarkeitsrisiko während der Übertragung.
Äußeres RADIUS-Paket
Klartext (über UDP oder TCP).
Verschlüsselt (über TLS).
Enthält sowohl Header als auch AVPs. Z. B. Paket sichtbar in Wireshark oder tcpdump.
Benutzeridentität (äußere Identität)
Im Klartext gesendet.
Verschlüsselt (über TLS).
[email protected] wird für Realm-Routing verwendet.
RADIUS AVPs (Attribute)
Einige im Klartext (z. B. NAS-IP, User-Name).
Vollständig in TLS verschlüsselt.
NAS-IP-Address,
Calling-Station-Id
RADIUS-Header
Klartext
In TLS verschlüsselt
Code (Access-Request), Identifier,
Länge,
Authenticator
RADIUS Shared Secret
Nicht übertragen (intern verwendet)
Nicht übertragen (intern verwendet)
Wird für AVP-Verschlüsselung und Message-Authenticator Validierung.
EAP-Payload
Zwischen Client und Server verschlüsselt
In TLS verschlüsselt
Enthält TLS-Handshake, Zertifikatsvalidierung usw.
Benutzeranmeldeinformationen (Zertifikate/Schlüssel)
Im EAP-Tunnel verschlüsselt
Im EAP-Tunnel + TLS verschlüsselt
Gilt für zertifikatbasierte (EAP-TLS) und passwortbasierte (PEAP) Methoden. Client-Zertifikat mit Subject CN=jsmith, OU=IT
Passwort (z. B. PEAP oder MSCHAPv2)
In getunnelter Methode verschlüsselt (z. B. PEAP)
Im EAP-Tunnel + TLS verschlüsselt
Gilt für passwortbasierte Methoden.
Identitätsschutz: äußere vs. innere Identität
EAP-Methoden, die Tunneling oder Zertifikate verwenden (z. B. PEAP, EAP-TTLS, EAP-TLS), unterstützen äußere und innere Identitäten:
Äußere Identität: Wird im Klartext im User-Name AVP gesendet, um Realm-Routing zu erleichtern. Oft anonymisiert (z. B.
[email protected]).Innere Identität: Wird sicher innerhalb des verschlüsselten EAP-Tunnels übertragen (z. B. Benutzername/Passwort, Zertifikat-CN).
Verhalten über verschiedene Transporte:
Bei RADIUSwird die äußere Identität im Klartext gesendet und ist im Netzwerk sichtbar.
Bei RadSecwird das gesamte Paket einschließlich der äußeren Identität verschlüsselt.
Datenschutzbedenken im Zusammenhang mit der Übertragung der äußeren Identität im Klartext mit RADIUS können durch Konfiguration von Identity Privacy oder durch Nutzung von Gerätezertifikaten, die keine personenbezogenen Daten im Common Name enthalten, gemindert werden
Hinweis: Einige Plattformen, wie der native EAP-Client von Windows, unterstützen Identity Privacy möglicherweise nicht standardmäßig in Methoden wie EAP-TLS und können dadurch die echte Identität in der äußeren Schicht offenlegen.
Äußere Identität
Die folgende Tabelle gibt einen Überblick über die typischen Werte, mit denen verschiedene Betriebssystemplattformen die äußere Identität befüllen.
Benutzername/Passwort
Typischerweise:
- UPN
- E-Mail-Adresse
Windows (kann anonymisiert werden)
iOS, iPadOS, macOS (kann anonymisiert werden)
Android (kann anonymisiert werden)
Gerätezertifikat
Common Name (CN)-Eigenschaft des Subject-Namens des Client-Zertifikats.
Typischerweise:
- DeviceName
- Intune-Geräte-ID (GUID)
- AAD-Geräte-ID (GUID)
Windows (kann nicht anonymisiert werden) *
iOS, iPadOS, macOS (kann anonymisiert werden)
Android (kann anonymisiert werden)
Benutzerzertifikat
Common Name (CN)-Eigenschaft des Subject-Namens des Client-Zertifikats.
Typischerweise:
- UPN
- E-Mail-Adresse
Windows (kann nicht anonymisiert werden)*
iOS, iPadOS, macOS (kann anonymisiert werden)
Android (kann anonymisiert werden)
*Der in Windows verwendete EAP-Client unterstützt für EAP-TLS keine Identity Privacy.
Protokollierungs- und Bereitstellungsüberlegungen
RadSec (TLS)
RadSec verschlüsselt das gesamte RADIUS-Paket, was passives Mithören verhindert. Dadurch verlagert sich Protokollierung und Diagnose von der Netzwerkinspektion auf die Anwendungsebene bzw. den RADIUS-Server, da diese die Endpunkte sind, die die TLS-Sitzung terminieren. Organisationen, die zu RadSec wechseln, sollten ihre Überwachungsabläufe evaluieren, um verschlüsselten Datenverkehr zu berücksichtigen.
RADIUS (UDP)
Die Klartextübertragung von Attributen (User-Name, NAS-IP-Address usw.) vereinfacht die Fehlersuche und Live-Diagnostik und ermöglicht Paketmitschnitte mit minimalem Werkzeugaufwand. Dies erhöht jedoch das Expositionsrisiko sensibler Metadaten während der Übertragung.
Netzwerkunterstützung
Die Unterstützung von RadSec ist nicht universell in allen Netzwerkgeräten und Infrastrukturen vorhanden. Viele Netzwerkswitches, Wireless Access Points und Firewalls unterstützen nur traditionelles RADIUS. In gemischten Umgebungen kann ein RadSec-zu-RADIUS-Proxy erforderlich sein, um moderne und Legacy-Komponenten zu überbrücken. Infrastrukturbewertungen werden vor der Produktionseinführung von RadSec empfohlen.
Fazit und zentrale Erkenntnisse
Der Transport von EAP-Methoden über RADIUS oder RadSec bietet denselben starken End-to-End-Schutz für Benutzeranmeldeinformationen, unterscheidet sich jedoch erheblich darin, wie Metadaten und Protokollelemente während der Übertragung offengelegt werden.
EAP End-to-End-Schutz: EAP bietet starken Schutz für Benutzeranmeldeinformationen sowohl über RADIUS als auch über RadSec.
Hauptunterschied: RADIUS verwendet UDP und verschlüsselt das RADIUS-Paket nicht selbst, während RadSec das gesamte Paket in TLS verpackt und dadurch alle Attribute und Header auf dem Übertragungsweg verbirgt.
Vertraulichkeit von Metadaten: RadSec verschlüsselt alle Metadaten (Header, Attribute und äußere Identität) und verhindert so eine Netzwerkeinblick-Exposition.
Gemeinsames Geheimnis: Das Shared Secret wird niemals übertragen. Es wird nur lokal verwendet, um Nachrichtenintegritätsprüfungen zu berechnen und Authentizität zu verifizieren.
Abwägungen: RadSec bietet verbesserte Vertraulichkeit, verkompliziert jedoch die Diagnose aufgrund der Verschlüsselung, und seine Unterstützung ist nicht bei allen Netzgeräteherstellern universell gegeben.
Standards und RFC-Referenzen
Für weitere Details zu Protokollen und Spezifikationen:
EAP (Extensible Authentication Protocol): RFC 3748
EAP-TLS: RFC 5216
RADIUS (Remote Authentication Dial-In User Service): RFC 2865
RadSec (RADIUS über TLS): RFC 6614
Zuletzt aktualisiert
War das hilfreich?