Zum Hauptinhalt springen

1.6. Abstract Service Interfaces (Abstrakte Service-Schnittstellen)

1.6. Abstract Service Interfaces (Abstrakte Service-Schnittstellen)​

Das benutzerbasierte Sicherheitsmodell ist so konzipiert, dass es sich über klar definierte abstrakte Service-Schnittstellen in die SNMPv3-Architektur integriert. Diese Schnittstellen ermöglichen es dem USM, unabhängig von anderen Subsystemen zu arbeiten und gleichzeitig die erforderlichen Sicherheitsdienste bereitzustellen.

Security Model Interface (Sicherheitsmodell-Schnittstelle)​

Das USM implementiert die in RFC 3411 definierte Sicherheitsmodell-Schnittstelle. Diese Schnittstelle besteht aus zwei primären Primitiven:

1. generateRequestMsg (Anforderungsnachricht generieren)​

Zweck (Purpose): Verarbeitung einer ausgehenden SNMP-Nachricht durch Hinzufügen sicherheitsrelevanter Informationen.

Eingaben (Inputs):

  • messageProcessingModel: Die SNMP-Version (3 für SNMPv3)
  • globalData: Globale Nachrichtenkopfzeileninfo
  • maxMessageSize: Unterstützte maximale Nachrichtengröße
  • securityModel: Sicherheitsmodellidentifikator (3 für USM)
  • securityEngineID: Der Identifikator der autoritativen SNMP-Engine
  • securityName: Der Principal, in dessen Namen die Nachricht generiert wird
  • securityLevel: Die gewünschte Sicherheitsstufe (noAuthNoPriv, authNoPriv oder authPriv)
  • scopedPDU: Die zu sichernde Nachrichtennutzlast

Ausgaben (Outputs):

  • securityParameters: USM-spezifische Sicherheitsparameter (engineID, engineBoots, engineTime, userName, Authentifizierungsparameter, Datenschutzparameter)
  • wholeMsg: Die vollständige gesicherte Nachricht, die zur Übertragung bereit ist
  • statusInformation: Erfolgs- oder Fehleranzeige

Verarbeitung (Processing):

  1. Eingaben validieren
  2. Authentifizierungs- und Datenschutzschlüssel des Benutzers abrufen
  3. engineBoots und engineTime inkrementieren und einschließen
  4. Datenschutzprotokoll anwenden, wenn securityLevel Datenschutz enthält
  5. Authentifizierungs-Digest berechnen, wenn securityLevel Authentifizierung enthält
  6. Vollständige Nachricht zusammenbauen

2. processIncomingMsg (Eingehende Nachricht verarbeiten)​

Zweck (Purpose): Verarbeitung einer eingehenden SNMP-Nachricht durch Überprüfung sicherheitsrelevanter Informationen.

Eingaben (Inputs):

  • messageProcessingModel: Die SNMP-Version
  • maxMessageSize: Unterstützte maximale Nachrichtengröße
  • securityParameters: Die empfangenen USM-Sicherheitsparameter
  • securityModel: Sicherheitsmodellidentifikator
  • securityLevel: Die erwartete Sicherheitsstufe
  • wholeMsg: Die empfangene vollständige Nachricht
  • securityEngineID: Der Identifikator der autoritativen Engine (aus der Nachricht)

Ausgaben (Outputs):

  • securityName: Der authentifizierte Principal
  • scopedPDU: Die entschlüsselte und verifizierte Nachrichtennutzlast
  • maxSizeResponseScopedPDU: Maximale Größe für Antwort
  • securityStateReference: Referenz zum Generieren von Antworten
  • statusInformation: Erfolgs- oder Fehleranzeige

Verarbeitung (Processing):

  1. securityParameters analysieren
  2. Überprüfen, ob msgAuthoritativeEngineID mit lokaler Engine übereinstimmt (für Befehlsresponder)
  3. Überprüfen, ob userName in usmUserTable existiert
  4. Zeitfenster überprüfen (engineBoots und engineTime)
  5. Nachricht entschlüsseln, wenn Datenschutz angewendet wurde
  6. Authentifizierungs-Digest überprüfen, wenn Authentifizierung angewendet wurde
  7. scopedPDU extrahieren und zurückgeben

Integration with Message Processing Subsystem (Integration mit Nachrichtenverarbeitungssubsystem)​

Das Nachrichtenverarbeitungssubsystem ruft das USM über diese Schnittstellen an bestimmten Punkten der Nachrichtenverarbeitung auf:

Für ausgehende Nachrichten (For Outgoing Messages):

Anwendung → Dispatcher → Nachrichtenverarbeitung → Sicherheitsmodell (USM) → Transport

Für eingehende Nachrichten (For Incoming Messages):

Transport → Dispatcher → Nachrichtenverarbeitung → Sicherheitsmodell (USM) → Anwendung

Interaction with Access Control (Interaktion mit Zugriffskontrolle)​

Das USM stellt den authentifizierten securityName dem Zugriffskontrollsubsystem (VACM) zur Verfügung, das ihn zur Bestimmung der Autorisierung verwendet:

  1. USM authentifiziert den Benutzer und stellt securityName bereit
  2. VACM verwendet securityName, securityModel und securityLevel zur Bestimmung der Zugriffsrechte
  3. VACM gewährt oder verweigert Zugriff basierend auf konfigurierten Richtlinien

Diese Trennung stellt sicher, dass:

  • USM sich konzentriert auf: "Wer sind Sie?" (Authentifizierung) und "Ist die Nachricht intakt?" (Integrität)
  • VACM sich konzentriert auf: "Was dürfen Sie tun?" (Autorisierung)

Error Handling and Reports (Fehlerbehandlung und Berichte)​

Wenn das USM einen Sicherheitsfehler erkennt, kann es einen Report-PDU generieren:

Häufige Fehlerszenarien (Common Error Scenarios):

  1. Unbekannte Engine-ID (Unknown Engine ID): usmStatsUnknownEngineIDs-Zähler inkrementiert

    • Während des Entdeckungsprozesses verwendet
    • Bericht enthält die engineID der lokalen Engine

  2. Zeitfenster-Verletzung (Time Window Violation): usmStatsNotInTimeWindows-Zähler inkrementiert

    • Während der Zeitsynchronisation verwendet
    • Bericht enthält aktuelle engineBoots und engineTime

  3. Authentifizierungsfehler (Authentication Failure): usmStatsWrongDigests-Zähler inkrementiert

    • Zeigt falsches Passwort/Schlüssel oder Nachrichtenmanipulation an
    • Bericht mit derselben Sicherheitsstufe wie empfangene Nachricht gesendet

  4. Entschlüsselungsfehler (Decryption Failure): usmStatsDecryptionErrors-Zähler inkrementiert

    • Zeigt falschen Datenschutzschlüssel oder Nachrichtenbeschädigung an
    • Bericht mit derselben Sicherheitsstufe wie empfangene Nachricht gesendet

  5. Unbekannter Benutzer (Unknown User): usmStatsUnknownUserNames-Zähler inkrementiert

    • Zeigt an, dass userName nicht in usmUserTable ist
    • Bericht ohne Authentifizierung gesendet

Service Primitive Sequences (Service-Primitiv-Sequenzen)​

Discovery Sequence (Entdeckungssequenz)​

1. Anwendung sendet Anfrage mit leerer engineID
2. USM generiert Nachricht mit securityLevel = noAuthNoPriv
3. Autoritative Engine empfängt Nachricht
4. USM erkennt unbekannte engineID
5. USM generiert Bericht mit usmStatsUnknownEngineIDs
6. Anwendung empfängt Bericht, lernt engineID

Time Synchronization Sequence (Zeitsynchronisationssequenz)​

1. Anwendung sendet Anfrage mit zwischengespeicherter engineID, Null engineBoots/Time
2. USM generiert authentifizierte Nachricht
3. Autoritative Engine empfängt Nachricht
4. USM erkennt Zeitfenster-Verletzung
5. USM generiert Bericht mit usmStatsNotInTimeWindows und aktuellen Zeitwerten
6. Anwendung empfängt Bericht, aktualisiert zwischengespeicherte Zeitwerte
7. Anwendung wiederholt ursprüngliche Anfrage mit synchronisierter Zeit

Authenticated Communication Sequence (Authentifizierte Kommunikationssequenz)​

1. Anwendung sendet Anfrage
2. USM generiert authentifizierte Nachricht mit aktuellen engineBoots/Time
3. USM berechnet Authentifizierungs-Digest
4. Autoritative Engine empfängt Nachricht
5. USM überprüft Zeitfenster
6. USM überprüft Authentifizierungs-Digest
7. USM extrahiert scopedPDU
8. Anwendung verarbeitet Anfrage
9. Anwendung generiert Antwort
10. USM generiert authentifizierte Antwortnachricht
11. Nicht-autoritative Engine empfängt Antwort
12. USM überprüft Authentifizierungs-Digest
13. USM extrahiert scopedPDU
14. Anwendung verarbeitet Antwort

Asynchronous vs. Synchronous Operation (Asynchrone vs. synchrone Operation)​

Die abstrakten Service-Schnittstellen sind so konzipiert, dass sie beides unterstützen:

Synchrone Operation (Synchronous Operation):

  • Anwendung wartet auf Antwort
  • Typisch für Befehlsgenerator/-responder-Modell

Asynchrone Operation (Asynchronous Operation):

  • Anwendung wartet nicht
  • Typisch für Benachrichtigungsinitiator/-empfänger-Modell

Das USM schreibt das Operationsmodell nicht vor; es stellt einfach Sicherheitsdienste bereit, unabhängig davon, wie die Anwendung zu operieren wählt.

Letztes Update am