Dieser Artikel wurde automatisch übersetzt. Die Übersetzung kann Ungenauigkeiten enthalten.
Zur englischen Originalversion wechseln.
Ctrlk

Transportsicherheit in RADIUS vs. RadSec

Bei der Bereitstellung sicherer Authentifizierung mit dem Extensible Authentication Protocol (EAP) spielt die Wahl des Transportprotokolls – RADIUS über UDP vs. RADIUS über TLS (RadSec) – eine entscheidende Rolle dabei, wie sicher Metadaten und Protokollelemente über das Netzwerk übertragen werden.

Sowohl RADIUS als auch RadSec können EAP-Nachrichten transportieren, einschließlich solcher, die in gängigen Methoden wie EAP-TLS, PEAP und EAP-TTLS verwendet werden. Während die internen 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, Attributoffenlegung, Auswirkungen auf das Logging und Bereitstellungsaspekte.

Transportsicherheit: Zentrale Unterschiede

EAP-Methoden wie EAP-TLS, PEAP und EAP-TTLS bieten Authentifizierungsmechanismen zwischen Clients (Supplicants) und Authentifizierungsservern. Diese Methoden verschlüsseln jedoch nicht automatisch den Transport von Metadaten zwischen Zwischenknoten. Diese Rolle übernimmt das Protokoll der Transportschicht:

  • RADIUS (UDP) überträgt EAP-Nachrichten und RADIUS-Attribute im Klartext.

  • RadSec (TLS) verschlüsselt das gesamte RADIUS-Paket und schützt dabei alle Attribute und Protokollheader während der Übertragung.

Die folgende Tabelle fasst diese Unterschiede zusammen, die sich auf die Vertraulichkeit von Attributen wie Outer Identity, NAS IP, Calling Station ID und mehr auswirken. Während EAP-Methoden möglicherweise Benutzeranmeldeinformationen (z. B. Zertifikate oder Kennwörter) verschlüsseln, bleiben Metadaten über Standard-RADIUS sichtbar, sofern nicht RadSec verwendet wird.

Protokoll
RADIUS
RadSec

Transportprotokoll der Schicht

UDP (typischerweise)

TLS über TCP

Verschlüsselung

Keine Transportverschlüsselung

Vollständige Transportverschlüsselung

Standardport*

UDP 1812

TCP 2083

Hinweise

Ohne Zustand; kann von Firewalls gefiltert werden.

Mit Zustand; stellt sichere Tunnel her.

*Diese Ports sind zwar die anerkannten Standards, einige Bereitstellungen können sie jedoch aus Gründen der lokalen Richtlinie oder Infrastruktur anpassen.

Die Rolle des RADIUS Shared Secret in beiden Protokollen

Das RADIUS Shared Secret wird für die Paketintegrität und veraltete Verschlüsselungsverhalten verwendet. Dies gilt unabhängig davon, ob der Transport über Standard-RADIUS oder RadSec erfolgt.

Wichtige Verwendungen:

  • Message-Authenticator AVP: Stellt die Paketintegrität mithilfe von HMAC-MD5 sicher.

  • User-Password AVP (veraltete Methoden): Verschlüsselt Anmeldeinformationen mithilfe des Shared Secret.

  • RadSec-Kompatibilität: Auch in RadSec bleibt das Shared Secret zur Kompatibilität mit RADIUS-Semantik und Zwischensystemen erhalten.

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 der Verwendung von EAP-TLS über RADIUS (UDP) und RadSec (TLS), gruppiert nach Sichtbarkeitsrisiko während der Übertragung.

Datenelement
RADIUS (UDP)
RadSec (RADIUS über TLS)
Beispiel / Hinweise

Äußeres RADIUS-Paket

Klartext (über UDP oder TCP).

Verschlüsselt (über TLS).

Enthält sowohl Header als auch AVPs. Z. B. im Paket in Wireshark oder tcpdump sichtbar.

Benutzeridentität (Outer Identity)

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,

Length,

Authenticator

RADIUS Shared Secret

Nicht übertragen (intern verwendet)

Nicht übertragen (intern verwendet)

Wird für AVP-Verschlüsselung und Message-Authenticator Validierung verwendet.

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 zertifikatsbasierte (EAP-TLS) und kennwortbasierte (PEAP) Methoden. Clientzertifikat mit Subject CN=jsmith, OU=IT

Kennwort (z. B. PEAP oder MSCHAPv2)

In der getunnelten Methode verschlüsselt (z. B. PEAP)

Im EAP-Tunnel + TLS verschlüsselt

Gilt für kennwortbasierte Methoden.

Identitätsschutz: Outer Identity vs. Inner Identity

EAP-Methoden, die Tunneling oder Zertifikate verwenden (z. B. PEAP, EAP-TTLS, EAP-TLS), unterstützen Outer und Inner Identity:

  • Outer Identity: Wird im Klartext im User-Name AVP gesendet, um das Realm-Routing zu erleichtern. Oft anonymisiert (z. B. [email protected]).

  • Inner Identity: Wird sicher innerhalb des verschlüsselten EAP-Tunnels übertragen (z. B. Benutzername/Kennwort, Zertifikats-CN).

Verhalten über die Transportwege hinweg:

  • In RADIUSwird die Outer Identity im Klartext gesendet und ist im Netzwerkverkehr sichtbar.

  • In RadSecist das gesamte Paket einschließlich der Outer Identity verschlüsselt.

Datenschutzbedenken im Zusammenhang mit der im Klartext über RADIUS übertragenen Outer Identity können durch die Konfiguration von Identitätsschutz oder durch die Nutzung von Gerätezertifikaten gemindert werden, die im Common-Name-Attribut keine personenbezogenen Daten (PII) enthalten

Hinweis: Einige Plattformen, wie der native EAP-Client von Windows, unterstützen den Identitätsschutz in Methoden wie EAP-TLS möglicherweise standardmäßig nicht, wodurch die echte Identität in der äußeren Schicht offengelegt werden kann.

Outer Identity

Die folgende Tabelle bietet einen Überblick über die typischen Werte, mit denen verschiedene Betriebssystemplattformen die Outer Identity befüllen.

Anmeldeinformationstyp
Outer Idenity
Anwendbares Betriebssystem

Benutzername/Kennwort

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 Clientzertifikats. Typischerweise: - Gerätename - Intune Device ID (GUID) - AAD Device 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 Clientzertifikats. Typischerweise: - UPN - E-Mail-Adresse

  • Windows (kann nicht anonymisiert werden)*

  • iOS, iPadOS, macOS (kann anonymisiert werden)

  • Android (kann anonymisiert werden)

*Der unter Windows verwendete EAP-Client unterstützt für EAP-TLS keinen Identitätsschutz.

Logging- und Bereitstellungsaspekte

RadSec (TLS)

RadSec verschlüsselt das gesamte RADIUS-Paket, wodurch passives Mithören verhindert wird. Dadurch verlagern sich Logging und Diagnose von der Netzwerkanalyse auf die Ebene der Anwendung oder des RADIUS-Servers, da diese die Endpunkte sind, die die TLS-Sitzung terminieren. Organisationen, die auf RadSec umstellen, sollten Überwachungsabläufe anpassen, um verschlüsselten Datenverkehr zu berücksichtigen.

RADIUS (UDP)

Die Klartextübertragung von Attributen (User-Name, NAS-IP-Address usw.) vereinfacht Fehlerbehebung und Live-Diagnose und ermöglicht Paketmitschnitte mit minimalen Werkzeugen. Gleichzeitig erhöht dies jedoch das Risiko, dass sensible Metadaten während der Übertragung offengelegt werden.

Netzwerkunterstützung

Die Unterstützung für RadSec ist nicht auf allen Netzwerkgeräten und in jeder Infrastruktur universell verfügbar. Viele Netzwerk-Switches, WLAN-Access Points und Firewalls unterstützen nur traditionelles RADIUS. In gemischten Umgebungen kann ein RadSec-zu-RADIUS-Proxy erforderlich sein, um moderne und ältere Komponenten zu verbinden. Vor der produktiven Einführung von RadSec werden Infrastrukturprüfungen empfohlen.

Fazit und wichtigste Erkenntnisse

Die Übertragung 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 sowohl über RADIUS als auch über RadSec starken Schutz für Benutzeranmeldeinformationen.

  • Hauptunterschied: RADIUS verwendet UDP und verschlüsselt das RADIUS-Paket selbst nicht, während RadSec das gesamte Paket in TLS einbettet und damit alle Attribute und Header aus dem Netzwerkverkehr verbirgt.

  • Vertraulichkeit von Metadaten: RadSec verschlüsselt alle Metadaten (Header, Attribute und Outer Identity) und verhindert so die Offenlegung auf Netzwerkebene.

  • Gemeinsames Geheimnis: Das Shared Secret wird niemals übertragen. Es wird nur lokal verwendet, um Integritätsprüfungen für Nachrichten zu berechnen und die Authentizität zu verifizieren.

  • Abwägungen: RadSec bietet eine verbesserte Vertraulichkeit, erschwert jedoch aufgrund der Verschlüsselung die Diagnose, und die Unterstützung ist nicht auf allen Netzwerkgeräten universell verfügbar.

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 over TLS): RFC 6614

Zuletzt aktualisiert

War das hilfreich?