In der servicebasierten 5G-Architektur kann eine AMF den SBI-Endpunkt einer UDM oder SMF ermitteln. Die reine Ermittlung erteilt jedoch noch keine Berechtigung, Teilnehmerdaten abzurufen oder eine PDU-Sitzung anzulegen. Die servicebasierte Kommunikation macht die Interaktion zwischen Netzwerkfunktionen flexibler, legt zugleich aber eine größere Zahl von Kernnetz-APIs offen. Verarbeitet ein NF-Dienstanbieter jede erreichbare Anfrage ohne Autorisierungsprüfung, kann er nicht zuverlässig feststellen, ob der Aufrufer legitim, registriert oder zur Nutzung des angeforderten Dienstes berechtigt ist.

Das 5GC löst dieses Problem mit einem auf OAuth 2.0 basierenden Autorisierungsmodell. Ein NF-Dienstnutzer fordert zunächst beim NRF ein Zugriffstoken an und legt dieses anschließend beim Aufruf des Ziel-NF-Dienstanbieters vor. Der Anbieter führt die angeforderte Operation erst aus, nachdem er das Token und dessen Autorisierungsansprüche geprüft hat. In diesem Modell fungiert das NRF nicht nur als Register- und Discovery-Funktion, sondern auch als Autorisierungsserver für geschützte SBI-Zugriffe.

Risiken ungeschützter SBI-Aufrufe

5G-Standalone-Netze nutzen die servicebasierte Architektur, in der Netzwerkfunktionen wie AMF, SMF, UDM und AUSF einen oder mehrere Dienste über HTTP/2-basierte servicebasierte Schnittstellen bereitstellen. Ein Nutzer kann diese Dienste über standardisierte HTTP-APIs aufrufen. Dadurch werden starre Punkt-zu-Punkt-Abhängigkeiten reduziert und Dienstbeziehungen können dynamisch aufgebaut werden.

Bei der UE-Registrierung kann die AMF beispielsweise den Nudm_SDM-Dienst der UDM aufrufen, um Teilnehmerdaten zu erhalten. Beim Aufbau einer PDU-Sitzung kann die AMF den Nsmf_PDUSession-Dienst der SMF aufrufen, um einen Sitzungsverwaltungskontext anzulegen. Beide Verfahren betreffen sensible Teilnehmerinformationen oder kritische Ressourcen des Kernnetzes.

Gibt die UDM Teilnehmerdaten allein deshalb zurück, weil die Anfrage den richtigen URI erreicht, hat sie keine Gewissheit, dass der Aufrufer eine autorisierte AMF ist. Ebenso könnte eine SMF, die eine Sitzung ohne Prüfung des Anfragenden anlegt, Aufrufe einer nicht vertrauenswürdigen oder falsch konfigurierten Netzwerkfunktion annehmen. Die Erreichbarkeit eines Endpunkts bestätigt lediglich, dass eine Kommunikation technisch möglich ist; Identität oder Berechtigung werden dadurch nicht nachgewiesen.

In cloudnativen Bereitstellungen nimmt dieses Risiko zu. NF-Instanzen können erstellt, skaliert, aktualisiert, verschoben oder entfernt werden, wenn sich betriebliche Anforderungen ändern. Ein Dienstnutzer kann über NRF-basierte Discovery außerdem unterschiedliche Anbieterinstanzen auswählen. Statische Adressen und feste Peer-Konfigurationen reichen daher nicht aus, um jede einzelne Dienstanforderung zu kontrollieren.

Das 5GC trennt Service Discovery und Service-Autorisierung. Die Discovery beantwortet, wo ein geeigneter Dienst verfügbar ist. Die Autorisierung entscheidet, ob der aktuelle Nutzer diesen Dienst verwenden darf. Bevor die fachliche Anfrage verarbeitet wird, muss der Nutzer einen zum vorgesehenen Dienst gehörenden Berechtigungsnachweis erhalten, den der Anbieter anschließend prüft.

Das NRF als Autorisierungsserver

OAuth 2.0 ist ein allgemeines Autorisierungsframework für kontrollierten Zugriff zwischen Anwendungen und nicht auf Mobilfunknetze beschränkt. Das Standardmodell definiert drei Hauptrollen: den Client, der Zugriff anfordert, den Autorisierungsserver, der ein Token ausstellt, und den Ressourcenserver, der die angeforderte Ressource oder den Dienst schützt.

Im SBI-Sicherheitsmodell des 5GC lassen sich diese Rollen direkt auf das Verhalten der Netzwerkfunktionen abbilden:

Muss eine AMF einen UDM-Dienst aufrufen, fungiert die AMF als NF-Dienstnutzer, die UDM als NF-Dienstanbieter und das NRF übernimmt die Autorisierungsfunktion. Vor dem Aufruf von Nudm_SDM beschafft sich die AMF ein Token. Anschließend prüft die UDM, ob das Token gültig ist und ob seine Claims den Zugriff auf den angeforderten Dienst erlauben.

Zur Unterstützung dieses Ablaufs stellt das NRF den Dienst Nnrf_AccessToken bereit. Eine Tokenanforderung kann Angaben wie die Identität des Nutzers, den Namen des angeforderten Dienstes, den Typ der Ziel-NF, den Typ der konsumierenden NF und die Clientkennung enthalten. Nach Bewertung der Anfrage liefert das NRF ein Zugriffstoken sowie zugehörige Informationen wie Tokentyp und Gültigkeitsdauer zurück.

Das NRF führt die angeforderte fachliche Operation nicht selbst aus. Es definiert den Autorisierungskontext und stellt den Zugriffsnachweis aus. Das Abrufen von Teilnehmerdaten, das Anlegen von Sitzungen und andere dienstspezifische Operationen bleiben Aufgabe des jeweiligen NF-Dienstanbieters.

Tokenbasierter Ablauf des Dienstzugriffs

Das für das 5GC definierte Verfahren zum Zugriff auf NF-Dienste lässt sich in zwei Phasen aufteilen. Zuerst erhält der Nutzer ein Zugriffstoken vom NRF. Anschließend legt er dieses Token beim Zielanbieter vor, wenn er den eigentlichen Dienst anfordert. Diese Trennung verhindert, dass eine ungeprüfte Anfrage direkt in die fachliche Verarbeitung gelangt.

Anfordern eines Zugriffstokens

Der NF-Dienstnutzer sollte zunächst über eine gültige Identität und einen dem NRF bekannten Registrierungskontext verfügen. Danach ruft er Nnrf_AccessToken auf und gibt den gewünschten Dienst, den Typ der Ziel-NF sowie seine eigenen Nutzerinformationen an.

Das NRF bewertet die Anfrage anhand der vorhandenen Registrierungsdaten und der Autorisierungsrichtlinie. Wird die Autorisierung erteilt, erzeugt es ein Zugriffstoken und gibt es an den Nutzer zurück. Zu diesem Zeitpunkt wurden weder eine Teilnehmerabfrage noch eine Sitzungserstellung oder eine andere fachliche Operation ausgeführt. Der Nutzer hat lediglich die Erlaubnis erhalten, den geschützten Dienst aufzurufen.

Aufruf des geschützten Dienstes

Der Nutzer sendet die fachliche Anfrage an den NF-Dienstanbieter und übermittelt das Zugriffstoken im HTTP-Header Authorization. Vor der Verarbeitung prüft der Anbieter Integrität, Gültigkeitszeitraum und Autorisierungsansprüche des Tokens. Der angeforderte Dienst wird nur ausgeführt, wenn diese Prüfungen erfolgreich sind.

Beim Aufbau einer PDU-Sitzung sendet die AMF zunächst eine HTTP/2-POST-Anfrage an den Nnrf_AccessToken-Dienst des NRF und gibt an, dass sie Zugriff auf den Nsmf_PDUSession-Dienst der SMF benötigt. Nach erfolgreicher Autorisierung gibt das NRF das Token in einer Antwort HTTP 200 OK zurück.

Anschließend sendet die AMF die Nsmf_PDUSession-Anfrage einschließlich Token an die ausgewählte SMF. Vor dem Anlegen des PDU-Sitzungsverwaltungskontexts prüft die SMF den Berechtigungsnachweis. Wird die Anfrage angenommen und der Kontext erfolgreich erstellt, kann die SMF mit HTTP 201 Created antworten.

Diese Reihenfolge setzt die Autorisierung vor die fachliche Ausführung. Die Kenntnis der SMF-Adresse und des API-Pfads reicht nicht aus. Ohne ein gültiges Token, das den vorgesehenen Dienst abdeckt, darf der Anfragende die reguläre Sitzungserstellung nicht fortsetzen.

Geltungsbereich und Entwurfsgrenzen

NRF-basierte Service Discovery und NRF-basierte Autorisierung stehen in Beziehung zueinander, sind jedoch getrennte Fähigkeiten. Die Discovery ermittelt verfügbare Anbieterinstanzen und deren unterstützte Dienste. Die Autorisierung entscheidet, ob ein bestimmter Nutzer einen dieser Dienste aufrufen darf. Eine abgeschlossene Discovery ersetzt nicht die Beschaffung eines geeigneten Tokens.

Das Zugriffstoken ersetzt auch keine fachlichen Daten. Das NRF ruft bei der Tokenausgabe keine UDM-Teilnehmerdaten ab und legt keine SMF-Sitzung an. Es weist nach, dass der Nutzer innerhalb eines definierten Umfangs autorisiert wurde. Die Verarbeitung der Anfrage und die Erzeugung der Antwort bleiben Aufgabe des Anbieters.

Eine sichere Implementierung erfordert die Durchsetzung auf Anbieterseite. Die Pflicht des Nutzers, ein Token anzufordern, bietet wenig Schutz, wenn der Anbieter Integrität, Ablaufzeit und Claims des Tokens nicht vor der Dienstausführung prüft. Nutzer, NRF und Anbieter müssen daher kompatible Regeln zur Tokenverarbeitung anwenden.

Die Autorisierung ist außerdem zeitlich und hinsichtlich ihres Umfangs begrenzt. Ein für einen SBI-Dienst ausgestelltes Token gewährt nicht automatisch uneingeschränkten Zugriff auf alle von anderen Netzwerkfunktionen bereitgestellten Schnittstellen. Abgelaufene Tokens oder Tokens, deren Claims nicht zum Zieldienst passen, dürfen nicht als gültige Berechtigungsnachweise behandelt werden.

Das NRF unterstützt damit zwei unterschiedliche sicherheitsbezogene Funktionen im 5G-Kernnetz. Es verwaltet NF-Profile und unterstützt die Service Discovery, damit Nutzer geeignete Anbieter finden können. Über Nnrf_AccessToken steuert es außerdem, ob diese Nutzer geschützte SBI-Dienste aufrufen dürfen.

Häufig gestellte Fragen

Kann ein Zugriffstoken die NF-Registrierung ersetzen?

Nein. Die NF-Registrierung stellt die Identität der Instanz und ihr Dienstprofil her. Ein Zugriffstoken erteilt eine Berechtigung für einen definierten Dienstzugriffskontext. Registrierung und Tokenausgabe erfüllen unterschiedliche Aufgaben.

Kann ein Token für mehrere NF-Instanzen verwendet werden?

Das hängt von den Token-Claims, dem Typ der Ziel-NF, dem Dienstumfang und der geltenden Autorisierungsrichtlinie ab. Jeder Anbieter muss prüfen, ob das Token für die aktuelle Anfrage gültig ist, statt es allein deshalb zu akzeptieren, weil es noch nicht abgelaufen ist.

Werden bestehende Tokens sofort ungültig, wenn das NRF nicht verfügbar ist?

Das Verhalten hängt vom Tokenformat, der Gültigkeitsdauer, der anbieterseitigen Prüfmethode und der Bereitstellungsrichtlinie ab. Ein vorübergehender NRF-Ausfall bestimmt nicht automatisch den Status aller zuvor ausgegebenen Tokens, kann jedoch neue Tokenanforderungen beeinträchtigen.

Verschlüsselt OAuth 2.0 den Inhalt von SBI-Nachrichten?

Nein. OAuth 2.0 dient in erster Linie der Autorisierung und Zugriffskontrolle. Der Schutz der SBI-Übertragung erfolgt durch separate Sicherheitsmechanismen wie TLS. Ein gültiges Zugriffstoken ist kein Ersatz für eine verschlüsselte Übertragung.