2. Elemente des Modells

Dieser Abschnitt enthält Definitionen, die zur Realisierung des in diesem Memo definierten Sicherheitsmodells erforderlich sind.

2.1. User-based Security Model Benutzer

Managementoperationen, die dieses Sicherheitsmodell verwenden, nutzen einen definierten Satz von Benutzeridentitäten. Für jeden Benutzer, in dessen Namen Managementoperationen an einer bestimmten SNMP-Engine autorisiert sind, muss diese SNMP-Engine Kenntnis von diesem Benutzer haben. Eine SNMP-Engine, die mit einer anderen SNMP-Engine kommunizieren möchte, muss auch Kenntnis von einem Benutzer haben, der dieser Engine bekannt ist, einschließlich Kenntnis der anwendbaren Attribute dieses Benutzers.

Ein Benutzer und seine Attribute sind wie folgt definiert:

• userName Eine Zeichenkette, die den Namen des Benutzers darstellt.

• securityName Eine für Menschen lesbare Zeichenkette, die den Benutzer in einem Format darstellt, das unabhängig vom Sicherheitsmodell ist. Es besteht eine Eins-zu-Eins-Beziehung zwischen userName und securityName.

• authProtocol Eine Angabe, ob Nachrichten, die im Namen dieses Benutzers gesendet werden, authentifiziert werden können, und wenn ja, welcher Typ von Authentifizierungsprotokoll verwendet wird. Zwei solche Protokolle sind in diesem Memo definiert:

  • das HMAC-MD5-96-Authentifizierungsprotokoll.
  • das HMAC-SHA-96-Authentifizierungsprotokoll.

• authKey Wenn Nachrichten, die im Namen dieses Benutzers gesendet werden, authentifiziert werden können, der (private) Authentifizierungsschlüssel zur Verwendung mit dem Authentifizierungsprotokoll. Beachten Sie, dass der Authentifizierungsschlüssel eines Benutzers normalerweise bei verschiedenen autoritativen SNMP-Engines unterschiedlich sein wird. Der authKey ist nicht über SNMP zugänglich. Die Längenanforderungen des authKey werden durch das verwendete authProtocol definiert.

• authKeyChange und authOwnKeyChange Die einzige Möglichkeit, den Authentifizierungsschlüssel remote zu aktualisieren. Dies geschieht auf sichere Weise, sodass die Aktualisierung abgeschlossen werden kann, ohne dass Datenschutzschutz erforderlich ist.

• privProtocol Eine Angabe, ob Nachrichten, die im Namen dieses Benutzers gesendet werden, vor Offenlegung geschützt werden können, und wenn ja, welcher Typ von Datenschutzprotokoll verwendet wird. Ein solches Protokoll ist in diesem Memo definiert: das CBC-DES Symmetric Encryption Protocol.

• privKey Wenn Nachrichten, die im Namen dieses Benutzers gesendet werden, ver-/entschlüsselt werden können, der (private) Datenschutzschlüssel zur Verwendung mit dem Datenschutzprotokoll. Beachten Sie, dass der Datenschutzschlüssel eines Benutzers normalerweise bei verschiedenen autoritativen SNMP-Engines unterschiedlich sein wird. Der privKey ist nicht über SNMP zugänglich. Die Längenanforderungen des privKey werden durch das verwendete privProtocol definiert.

• privKeyChange und privOwnKeyChange Die einzige Möglichkeit, den Verschlüsselungsschlüssel remote zu aktualisieren. Dies geschieht auf sichere Weise, sodass die Aktualisierung abgeschlossen werden kann, ohne dass Datenschutzschutz erforderlich ist.

2.2. Replay-Schutz

Jede SNMP-Engine verwaltet drei Objekte:

• snmpEngineID, die (zumindest innerhalb einer Verwaltungsdomäne) eine SNMP-Engine eindeutig und unzweideutig identifiziert.

• snmpEngineBoots, das ist eine Zählung der Anzahl der Male, die die SNMP-Engine seit der letzten Konfiguration der snmpEngineID neu gestartet/neu initialisiert wurde; und,

• snmpEngineTime, das ist die Anzahl der Sekunden seit der letzten Inkrementierung des snmpEngineBoots-Zählers.

Jede SNMP-Engine ist in Bezug auf diese Objekte in ihrer eigenen SNMP-Entität immer autoritativ. Es liegt in der Verantwortung einer nicht-autoritativen SNMP-Engine, sich gegebenenfalls mit der autoritativen SNMP-Engine zu synchronisieren.

Eine autoritative SNMP-Engine muss die Werte ihrer snmpEngineID und snmpEngineBoots in nichtflüchtigem Speicher verwalten.

2.2.1. msgAuthoritativeEngineID

Der in einer authentifizierten Nachricht enthaltene msgAuthoritativeEngineID-Wert wird verwendet, um Angriffe abzuwehren, bei denen Nachrichten von einer SNMP-Engine zu einer anderen SNMP-Engine zu einer anderen SNMP-Engine wiedergegeben werden. Er repräsentiert die snmpEngineID bei der autoritativen SNMP-Engine, die am Austausch der Nachricht beteiligt ist.

Wenn eine autoritative SNMP-Engine zum ersten Mal installiert wird, setzt sie ihren lokalen Wert von snmpEngineID gemäß einem unternehmensspezifischen Algorithmus (siehe die Definition der Textual Convention für SnmpEngineID im SNMP Architecture-Dokument [RFC3411]).

2.2.2. msgAuthoritativeEngineBoots und msgAuthoritativeEngineTime

Die in einer authentifizierten Nachricht enthaltenen Werte msgAuthoritativeEngineBoots und msgAuthoritativeEngineTime werden verwendet, um Angriffe abzuwehren, bei denen Nachrichten wiedergegeben werden, wenn sie nicht mehr gültig sind. Sie repräsentieren die snmpEngineBoots- und snmpEngineTime-Werte bei der autoritativen SNMP-Engine, die am Austausch der Nachricht beteiligt ist.

Durch die Verwendung von snmpEngineBoots und snmpEngineTime besteht für eine SNMP-Engine keine Anforderung, eine nichtflüchtige Uhr zu haben, die tickt (d.h. mit dem Ablauf der Zeit zunimmt), auch wenn die SNMP-Engine ausgeschaltet ist. Stattdessen ruft sie jedes Mal, wenn eine SNMP-Engine neu startet, snmpEngineBoots ab, inkrementiert es und speichert es dann in nichtflüchtigem Speicher und setzt snmpEngineTime auf Null zurück.

Wenn eine SNMP-Engine zum ersten Mal installiert wird, setzt sie ihre lokalen Werte von snmpEngineBoots und snmpEngineTime auf Null. Wenn snmpEngineTime jemals seinen Maximalwert (2147483647) erreicht, wird snmpEngineBoots inkrementiert, als ob die SNMP-Engine neu gestartet hätte, und snmpEngineTime wird auf Null zurückgesetzt und beginnt erneut zu inkrementieren.

Jedes Mal, wenn eine autoritative SNMP-Engine neu startet, müssen alle SNMP-Engines, die die Werte snmpEngineBoots und snmpEngineTime dieser autoritativen SNMP-Engine halten, neu synchronisieren, bevor sie korrekt authentifizierte Nachrichten an diese autoritative SNMP-Engine senden (siehe Abschnitt 2.3 für (Re-)Synchronisierungsverfahren). Beachten Sie jedoch, dass die Verfahren vorsehen, dass eine Benachrichtigung von einer empfangenden SNMP-Engine als authentisch akzeptiert wird, wenn sie von einer autoritativen SNMP-Engine gesendet wird, die seit der letzten (Re-)Synchronisierung der empfangenden SNMP-Engine neu gestartet wurde.

Wenn eine autoritative SNMP-Engine jemals nicht in der Lage ist, ihren neuesten snmpEngineBoots-Wert zu bestimmen, muss sie ihren snmpEngineBoots-Wert auf 2147483647 setzen.

Immer wenn der lokale Wert von snmpEngineBoots den Wert 2147483647 hat, rastet er bei diesem Wert ein, und eine authentifizierte Nachricht verursacht immer einen notInTimeWindow-Authentifizierungsfehler.

Um eine SNMP-Engine, deren snmpEngineBoots-Wert den Wert 2147483647 erreicht hat, zurückzusetzen, ist ein manueller Eingriff erforderlich. Die Engine muss physisch besucht und neu konfiguriert werden, entweder mit einem neuen snmpEngineID-Wert oder mit neuen geheimen Werten für die Authentifizierungs- und Datenschutzprotokolle aller Benutzer, die dieser SNMP-Engine bekannt sind. Beachten Sie, dass selbst wenn eine SNMP-Engine einmal pro Sekunde neu startet, es immer noch etwa 68 Jahre dauern würde, bis der Maximalwert von 2147483647 erreicht wäre.

2.2.3. Zeitfenster

Das Zeitfenster ist ein Wert, der das Zeitfenster angibt, in dem eine im Namen eines Benutzers generierte Nachricht gültig ist. Dieses Memo legt fest, dass derselbe Wert des Zeitfensters, 150 Sekunden, für alle Benutzer verwendet wird.

2.3. Zeitsynchronisierung

Zeitsynchronisierung, die von einer nicht-autoritativen SNMP-Engine benötigt wird, um mit authentischen Kommunikationen fortzufahren, hat stattgefunden, wenn die nicht-autoritative SNMP-Engine eine lokale Vorstellung von den Werten snmpEngineBoots und snmpEngineTime der autoritativen SNMP-Engine von der autoritativen SNMP-Engine erhalten hat. Diese Werte müssen innerhalb des Zeitfensters der autoritativen SNMP-Engine liegen (und bleiben). Daher muss die lokale Vorstellung der Werte der autoritativen SNMP-Engine lose mit den bei der autoritativen SNMP-Engine gespeicherten Werten synchronisiert bleiben. Zusätzlich zur Aufbewahrung einer lokalen Kopie von snmpEngineBoots und snmpEngineTime von der autoritativen SNMP-Engine muss eine nicht-autoritative SNMP-Engine auch eine lokale Variable latestReceivedEngineTime führen. Dieser Wert zeichnet den höchsten Wert von snmpEngineTime auf, der von der nicht-autoritativen SNMP-Engine von der autoritativen SNMP-Engine empfangen wurde, und wird verwendet, um die Möglichkeit des Wiedergebens von Nachrichten zu eliminieren, die verhindern würden, dass die Vorstellung der nicht-autoritativen SNMP-Engine von der snmpEngineTime voranschreitet.

Eine nicht-autoritative SNMP-Engine muss lokale Vorstellungen dieser Werte (snmpEngineBoots, snmpEngineTime und latestReceivedEngineTime) für jede autoritative SNMP-Engine führen, mit der sie kommunizieren möchte. Da jede autoritative SNMP-Engine eindeutig und unzweideutig durch ihren Wert von snmpEngineID identifiziert wird, kann die nicht-autoritative SNMP-Engine diesen Wert als Schlüssel verwenden, um ihre lokalen Vorstellungen dieser Werte zu cachen.

Zeitsynchronisierung erfolgt als Teil der Verfahren zum Empfangen einer SNMP-Nachricht (Abschnitt 3.2, Schritt 7b). Als solches ist kein explizites Zeitsynchronisierungsverfahren durch eine nicht-autoritative SNMP-Engine erforderlich. Beachten Sie, dass immer wenn der lokale Wert von snmpEngineID geändert wird (z.B. durch Erkennung) oder wenn sichere Kommunikationen zum ersten Mal mit einer autoritativen SNMP-Engine hergestellt werden, die lokalen Werte von snmpEngineBoots und latestReceivedEngineTime auf Null gesetzt werden sollten. Dies bewirkt, dass die Zeitsynchronisierung erfolgt, wenn die nächste authentische Nachricht empfangen wird.

2.4. SNMP-Nachrichten, die dieses Sicherheitsmodell verwenden

Die Syntax einer SNMP-Nachricht, die dieses Sicherheitsmodell verwendet, entspricht dem im versionsspezifischen Message Processing Model-Dokument definierten Nachrichtenformat (z.B. [RFC3412]).

Das Feld msgSecurityParameters in SNMPv3-Nachrichten hat einen Datentyp von OCTET STRING. Sein Wert ist die BER-Serialisierung der folgenden ASN.1-Sequenz:

USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN

   UsmSecurityParameters ::=
       SEQUENCE {
        -- globale benutzerbasierte Sicherheitsparameter
           msgAuthoritativeEngineID     OCTET STRING,
           msgAuthoritativeEngineBoots  INTEGER (0..2147483647),
           msgAuthoritativeEngineTime   INTEGER (0..2147483647),
           msgUserName                  OCTET STRING (SIZE(0..32)),
        -- authentifizierungsprotokollspezifische Parameter
           msgAuthenticationParameters  OCTET STRING,
        -- datenschutzprotokollspezifische Parameter
           msgPrivacyParameters         OCTET STRING
       }
END

Die Felder dieser Sequenz sind:

• Die msgAuthoritativeEngineID gibt die snmpEngineID der autoritativen SNMP-Engine an, die am Austausch der Nachricht beteiligt ist.

• Die msgAuthoritativeEngineBoots gibt den snmpEngineBoots-Wert bei der autoritativen SNMP-Engine an, die am Austausch der Nachricht beteiligt ist.

• Die msgAuthoritativeEngineTime gibt den snmpEngineTime-Wert bei der autoritativen SNMP-Engine an, die am Austausch der Nachricht beteiligt ist.

• Der msgUserName gibt den Benutzer (Prinzipal) an, in dessen Namen die Nachricht ausgetauscht wird. Beachten Sie, dass ein userName mit der Länge Null keinem Benutzer entspricht, aber für die snmpEngineID-Erkennung verwendet werden kann.

• Die msgAuthenticationParameters werden durch das für die Nachricht verwendete Authentifizierungsprotokoll definiert, wie in der Spalte usmUserAuthProtocol im Eintrag des Benutzers in der usmUserTable definiert.

• Die msgPrivacyParameters werden durch das für die Nachricht verwendete Datenschutzprotokoll definiert, wie in der Spalte usmUserPrivProtocol im Eintrag des Benutzers in der usmUserTable definiert.

Siehe Anhang A.4 für ein Beispiel der BER-Codierung des Feldes msgSecurityParameters.

2.5. Vom User-based Security Model bereitgestellte Dienste

Dieser Abschnitt beschreibt die vom User-based Security Model bereitgestellten Dienste mit ihren Ein- und Ausgaben.

Die Dienste werden als Primitive einer abstrakten Dienstschnittstelle beschrieben, und die Ein- und Ausgaben werden als abstrakte Datenelemente beschrieben, wie sie in diesen abstrakten Dienstprimitiven übergeben werden.

2.5.1. Dienste zum Generieren einer ausgehenden SNMP-Nachricht

Wenn das Message Processing (MP) Subsystem das User-based Security-Modul aufruft, um eine ausgehende SNMP-Nachricht zu sichern, muss es den vom Sicherheitsmodul bereitgestellten geeigneten Dienst verwenden. Diese zwei Dienste werden bereitgestellt:

1. Ein Dienst zum Generieren einer Request-Nachricht. Das abstrakte Dienstprimitiv ist:

statusInformation =            -- Erfolg oder Fehleranzeige
  generateRequestMsg(
  IN   messageProcessingModel  -- typischerweise SNMP-Version
  IN   globalData              -- Nachrichtenheader, Verwaltungsdaten
  IN   maxMessageSize          -- der sendenden SNMP-Entität
  IN   securityModel           -- für die ausgehende Nachricht
  IN   securityEngineID        -- autoritative SNMP-Entität
  IN   securityName            -- im Namen dieses Prinzipals
  IN   securityLevel           -- angeforderter Sicherheitslevel
  IN   scopedPDU               -- Nachrichten-(Klartext-)Payload
  OUT  securityParameters      -- vom Sicherheitsmodul ausgefüllt
  OUT  wholeMsg                -- vollständige generierte Nachricht
  OUT  wholeMsgLength          -- Länge der generierten Nachricht
       )

2. Ein Dienst zum Generieren einer Response-Nachricht. Das abstrakte Dienstprimitiv ist:

statusInformation =            -- Erfolg oder Fehleranzeige
  generateResponseMsg(
  IN   messageProcessingModel  -- typischerweise SNMP-Version
  IN   globalData              -- Nachrichtenheader, Verwaltungsdaten
  IN   maxMessageSize          -- der sendenden SNMP-Entität
  IN   securityModel           -- für die ausgehende Nachricht
  IN   securityEngineID        -- autoritative SNMP-Entität
  IN   securityName            -- im Namen dieses Prinzipals
  IN   securityLevel           -- angeforderter Sicherheitslevel
  IN   scopedPDU               -- Nachrichten-(Klartext-)Payload
  IN   securityStateReference  -- Verweis auf Sicherheitszustand
                               -- Informationen aus der ursprünglichen
                               -- Anfrage
  OUT  securityParameters      -- vom Sicherheitsmodul ausgefüllt
  OUT  wholeMsg                -- vollständige generierte Nachricht
  OUT  wholeMsgLength          -- Länge der generierten Nachricht
       )

Die als Parameter in den abstrakten Dienstprimitiven übergebenen abstrakten Datenelemente sind wie folgt:

• statusInformation Eine Angabe, ob die Codierung und Sicherung der Nachricht erfolgreich war. Wenn nicht, ist es eine Angabe des Problems.

• messageProcessingModel Die SNMP-Versionsnummer für die zu generierende Nachricht. Diese Daten werden vom User-based Security-Modul nicht verwendet.

• globalData Der Nachrichtenheader (d.h. seine Verwaltungsinformationen). Diese Daten werden vom User-based Security-Modul nicht verwendet.

• maxMessageSize Die maximale Nachrichtengröße, wie in der Nachricht enthalten. Diese Daten werden vom User-based Security-Modul nicht verwendet.

• securityParameters Dies sind die Sicherheitsparameter. Sie werden vom User-based Security-Modul ausgefüllt.

• securityModel Das verwendete securityModel. Sollte User-based Security Model sein. Diese Daten werden vom User-based Security-Modul nicht verwendet.

• securityName Zusammen mit der snmpEngineID identifiziert es eine Zeile in der usmUserTable, die zum Sichern der Nachricht verwendet werden soll. Der securityName hat ein Format, das unabhängig vom Sicherheitsmodell ist. Im Fall einer Antwort wird dieser Parameter ignoriert, und der Wert aus dem Cache wird verwendet.

• securityLevel Der Sicherheitslevel, aus dem das User-based Security-Modul bestimmt, ob die Nachricht vor Offenlegung geschützt werden muss und ob die Nachricht authentifiziert werden muss.

• securityEngineID Die snmpEngineID der autoritativen SNMP-Engine, an die eine dateRequest-Nachricht gesendet werden soll. Im Fall einer Antwort wird impliziert, dass es die snmpEngineID der verarbeitenden SNMP-Engine ist, und wenn sie angegeben ist, wird sie ignoriert.

• scopedPDU Die Nachrichtennutzlast. Die Daten sind opak, soweit es das User-based Security Model betrifft.

• securityStateReference Ein Handle/Verweis auf cachedSecurityData, das beim Sichern einer ausgehenden Response-Nachricht verwendet werden soll. Dies ist genau derselbe Handle/Verweis, wie er vom User-based Security-Modul beim Verarbeiten der eingehenden Request-Nachricht generiert wurde, auf die dies die Response-Nachricht ist.

• wholeMsg Die vollständig codierte und gesicherte Nachricht, bereit zum Senden über die Leitung.

• wholeMsgLength Die Länge der codierten und gesicherten Nachricht (wholeMsg).

Nach Abschluss des Prozesses gibt das User-based Security-Modul statusInformation zurück. Wenn der Prozess erfolgreich war, wird die fertige Nachricht mit angewendetem Datenschutz und Authentifizierung zurückgegeben, wenn dies vom angegebenen securityLevel angefordert wurde. Wenn der Prozess nicht erfolgreich war, wird eine Fehleranzeige zurückgegeben.

2.5.2. Dienste zur Verarbeitung einer eingehenden SNMP-Nachricht

Wenn das Message Processing (MP) Subsystem das User-based Security-Modul aufruft, um die ordnungsgemäße Sicherheit einer eingehenden Nachricht zu überprüfen, muss es den für eine eingehende Nachricht bereitgestellten Dienst verwenden. Das abstrakte Dienstprimitiv ist:

statusInformation =             -- Fehleranzeige oder Erfolg
                                -- Fehlerzähler OID/Wert bei Fehler
  processIncomingMsg(
  IN   messageProcessingModel   -- typischerweise SNMP-Version
  IN   maxMessageSize           -- der sendenden SNMP-Entität
  IN   securityParameters       -- für die empfangene Nachricht
  IN   securityModel            -- für die empfangene Nachricht
  IN   securityLevel            -- Sicherheitslevel
  IN   wholeMsg                 -- wie auf der Leitung empfangen
  IN   wholeMsgLength           -- Länge wie auf der Leitung empfangen
  OUT  securityEngineID         -- autoritative SNMP-Entität
  OUT  securityName             -- Identifikation des Prinzipals
  OUT  scopedPDU,               -- Nachrichten-(Klartext-)Payload
  OUT  maxSizeResponseScopedPDU -- maximale Größe der Response-PDU
  OUT  securityStateReference   -- Verweis auf Sicherheitszustand
       )                        -- Informationen, für Antwort benötigt

Die als Parameter in den abstrakten Dienstprimitiven übergebenen abstrakten Datenelemente sind wie folgt:

• statusInformation Eine Angabe, ob der Prozess erfolgreich war oder nicht. Wenn nicht, enthält die statusInformation die OID und den Wert des Fehlerzählers, der inkrementiert wurde.

• messageProcessingModel Die in der Nachricht empfangene SNMP-Versionsnummer. Diese Daten werden vom User-based Security-Modul nicht verwendet.

• maxMessageSize Die maximale Nachrichtengröße, wie in der Nachricht enthalten. Das User-based Security-Modul verwendet diesen Wert, um die maxSizeResponseScopedPDU zu berechnen.

• securityParameters Dies sind die in der Nachricht empfangenen Sicherheitsparameter.

• securityModel Das verwendete securityModel. Sollte das User-based Security Model sein. Diese Daten werden vom User-based Security-Modul nicht verwendet.

• securityLevel Der Sicherheitslevel, aus dem das User-based Security-Modul bestimmt, ob die Nachricht vor Offenlegung geschützt werden muss und ob die Nachricht authentifiziert werden muss.

• wholeMsg Die gesamte Nachricht, wie sie empfangen wurde.

• wholeMsgLength Die Länge der Nachricht, wie sie empfangen wurde (wholeMsg).

• securityEngineID Die snmpEngineID, die aus dem Feld msgAuthoritativeEngineID extrahiert wurde und die verwendet wurde, um die Geheimnisse in der usmUserTable nachzuschlagen.

• securityName Der Sicherheitsname, der den Benutzer repräsentiert, in dessen Namen die Nachricht empfangen wurde. Der securityName hat ein Format, das unabhängig vom Sicherheitsmodell ist.

• scopedPDU Die Nachrichtennutzlast. Die Daten sind opak, soweit es das User-based Security Model betrifft.

• maxSizeResponseScopedPDU Die maximale Größe einer scopedPDU, die in einer möglichen Response-Nachricht enthalten sein soll. Das User-based Security-Modul berechnet diese Größe basierend auf der msgMaxSize (wie in der Nachricht empfangen) und dem für eine solche Response-Nachricht erforderlichen Raum für den Nachrichtenheader (einschließlich der securityParameters).

• securityStateReference Ein Handle/Verweis auf cachedSecurityData, das beim Sichern einer ausgehenden Response-Nachricht verwendet werden soll. Wenn das Message Processing Subsystem das User-based Security-Modul aufruft, um eine Antwort auf diese eingehende Nachricht zu generieren, muss es diesen Handle/Verweis übergeben.

Nach Abschluss des Prozesses gibt das User-based Security-Modul statusInformation zurück und, wenn der Prozess erfolgreich war, die zusätzlichen Datenelemente zur weiteren Verarbeitung der Nachricht. Wenn der Prozess nicht erfolgreich war, wird eine Fehleranzeige, möglicherweise mit einem OID- und Wertpaar eines Fehlerzählers, der inkrementiert wurde, zurückgegeben.

2.6. Schlüssellokalisierungsalgorithmus

Ein lokalisierter Schlüssel ist ein geheimer Schlüssel, der zwischen einem Benutzer U und einer autoritativen SNMP-Engine E geteilt wird. Obwohl ein Benutzer möglicherweise nur ein Passwort und daher einen Schlüssel für das gesamte Netzwerk hat, sind die tatsächlichen Geheimnisse, die zwischen dem Benutzer und jeder autoritativen SNMP-Engine geteilt werden, unterschiedlich. Dies wird durch Schlüssellokalisierung [Localized-key] erreicht.

Zunächst wird, wenn ein Benutzer ein Passwort verwendet, das Passwort des Benutzers unter Verwendung eines der beiden in Anhängen A.2.1 und A.2.2 beschriebenen Algorithmen in einen Schlüssel Ku umgewandelt.

Um den Schlüssel Ku in einen lokalisierten Schlüssel Kul des Benutzers U bei der autoritativen SNMP-Engine E umzuwandeln, hängt man die snmpEngineID der autoritativen SNMP-Engine an den Schlüssel Ku an und hängt dann den Schlüssel Ku an das Ergebnis an, wodurch die snmpEngineID innerhalb der zwei Kopien des Benutzerschlüssels Ku eingeschlossen wird. Dann führt man eine sichere Hash-Funktion aus (welche davon hängt vom für diesen Benutzer U bei der autoritativen SNMP-Engine E definierten Authentifizierungsprotokoll ab; dieses Dokument definiert zwei Authentifizierungsprotokolle mit ihren zugehörigen Algorithmen basierend auf MD5 und SHA). Die Ausgabe der Hash-Funktion ist der lokalisierte Schlüssel Kul für Benutzer U bei der autoritativen SNMP-Engine E.