DE60026721T2 - System und verfahren zur initialisierung eines "simple network management protocol" (snmp) agenten - Google Patents

Description

• HINTERGRUND
• 1. Technisches Gebiet:
• Die vorliegende Anmeldung betrifft im Allgemeinen ein System und ein Verfahren zum Initialisieren eines SNMP-(simple network management protocol-)Agenten und insbesondere ein System und ein Verfahren zum Erzeugen von Authentifikations- und Geheimhaltungsschlüsseln für einen ersten Anwender einer SNMPv3-netzwerkverwalteten Einrichtung und zum sicheren Eingeben der Schlüssel in die Einrichtung, um die Einrichtung in eine SNMPv3-Betriebsart zu initialisieren.
• 2. Beschreibung der in Beziehung stehenden Technik:
• Im Allgemeinen ist das SNMP ein Standardprotokoll der Anwendungsschicht, das in einem Netzwerk eingesetzt wird, um den Austausch von Verwaltungsinformationen zwischen vernetzten Einrichtungen zu vereinfachen. Das SNMPv3-Framework definiert Standardsicherheits- bzw. -zugriffssteuerprotokolle, die als das User-Based Security Model (USM) bzw. das View-Based Access Control Model (VACM) bekannt sind. Der SMMPv3-Standard ist ein erweiterbares "gerüstartiges" Protokoll, das Anbietern ermöglicht, proprietäre MIB-(management information base-)Elemente und Anwendungen zu umfassen, um sie oben auf dem Standard-SNMP-Framework auszuführen.
• Ein SNMP-Netzwerk umfasst im Allgemeinen eine Vielzahl an verteilten SNMP-Einheiten, wobei jede einen oder mehrere SNMP-Agenten und einen oder mehrere SNMP-Manager (obwohl eine Einheit sowohl einen Agenten als auch einen Manager umfassen kann) umfasst, die unter Verwendung von SNMP-Nachrichten kommunizieren. Ein SNMP-Manager (oder eine NMS (network management station)) ist verantwortlich dafür, einen oder mehrere SNMP-Agenten in der Domain des SNMP-Managers zu verwalten. An jedem Knoten (oder Host) des Netzwerks (z.B. Computer, Server, etc.) ist ein SNMP-Agent enthalten, der durch einen SNMP-Manager verwaltet wird. Jeder Agent ist dafür verantwortlich, Informationen über seine Umgebung zu sammeln und zu halten, und solche Informationen einem jeweiligen SNMP-Manager bereitzustellen, und Manager-Befehlen zu antworten, um die lokale Konfiguration oder die Betriebsparameter des verwalteten Knotens zu ändern. Jeder SNMP-Agent hält eine lokale MIB (management information base oder Verwaltungsinformationsdatenbank), die ein Speicher für virtuelle Informationen ist, der Verwaltungsinformationen umfasst, das heißt momentane und historische Informationen über die lokale Konfiguration und den Verkehr der verwalteten Einrichtung (Knoten). Spezieller umfasst die MIB des SNMP-Agenten eine Sammlung von verwalteten Objekten in der Einrichtung, die verwaltet werden soll, wobei Sammlungen von in Beziehung stehenden Objekten in MIB-Modulen definiert sind.
• In einer SNMPv3-Betriebsart implementiert ein SNMP-Agent das Standard-USM (user-based security model oder benutzerbasiertes Sicherheitsmodell), wobei die Konfigurationsparameter für das USM über MIB-Elemente verwaltet werden, die durch das SNMP-USER-BASED-SM-MIB-Modul definiert sind (das beispielsweise ausführlich in RFC 2574, "User-Based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)" von Blumenthal et al., April 1999, beschrieben ist). Wie es in der Technik für das USM bekannt ist, verwenden alle gültigen Anwender, die zu einem SNMPv3-Agenten gehören, einen einzigartigen geheimen Authentifikationsschlüssel und einen einzigartigen Geheimhal tungsschlüssel (und Standardprotokolle) für eine Authentifikation von eingehenden/ausgehenden Nachrichten und ein Verschlüsseln/Entschlüsseln der Nutzdaten von eingehenden/ausgehenden Nachrichten. Des weiteren verwendet in einer SNMPv3-Betriebsart der SNMP-Agent das View-based Access Control Model (VACM), das durch den Agenten (in Ansprechen auf einen Anruf durch eine SNMP-Anwendung) verwendet wird, um zu bestimmen, ob ein spezifischer Typ von Zugriff (lesen, schreiben) für einen SNMP-Manager, der anfragt, um lokale MIB-verwaltete Daten abzufragen oder zu modifizieren, autorisiert ist, oder ob der Manager autorisiert ist, um Meldungen (Traps) von dem Agenten zu empfangen. Die Konfigurationsparameter für das VACM werden über MIB-Elemente verwaltet, die durch die SNMP-VIEW-BASED-ACM-MIB definiert sind, wie es zum Beispiel in RFC 2575, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)" von Wijnen, et al., April 1999) detailliert beschrieben ist. Das Schriftstück "SNMPv3 can still be simple?" von Cherkaoui, Mai 1999, betrifft die Sicherheit des SNMPv3-Frameworks.
• Verschiedene Anwendungen und Netzwerkarchitekturen implementieren das SNMP-Framework. Zum Beispiel wurde das SNMP-Protokoll als das Kommunikationsprotokoll für eine Verwaltung von DOCSIS-(Data Over Cable Service Interface Specifications-)basierten Kabelmodemsystemen ausgewählt. Die DOCSIS-Kabelmodems sind mit SNMP-Agenten ausgebildet, was einem Manager (Bediener des DOCSIS-Kabelmodemsystems) ermöglicht, die Kabelmodems der Endanwender aus einer Entfernung zu verwalten und zu konfigurieren. Das momentane DOCSIS-Kabelmodemsystem-Framework stellt jedoch kein Standardprotokoll zum Eingeben der anfänglichen Authentifikations- und Geheimhaltungsschlüssel in ein Kabelmodem bereit, um das Kabelmodem in eine SNMPv3-Betriebsart zu ini tialisieren, und Anbieter müssen proprietäre Protokolle zum Ausführen dieser Initialisierung bereitstellen.
• Das SNMPv3-Framework empfiehlt, dass die usmUserTable aus einem Band besetzt werden soll, zum Beispiel nicht unter Verwendung des SNMP (d.h. der erste Anwender muss erzeugt werden, und seine Autorisierungs- und Geheimhaltungsschlüssel müssen in die verwaltete Einrichtung eingegeben werden, ohne das SNMP zu verwenden). Das SNMP kann für diese Initialisierung nicht verwendet werden, da es eine Geheimhaltung nur durch Verwenden des Geheimhaltungsschlüssels eines bereits existierenden Anwenders bereitstellt. Wenn die Anzahl von Agenten, die initialisiert werden sollen, klein ist, kann ein Initialisierungsvorgang über einen Konsolenport oder manuell ausgeführt werden. Wenn die Anzahl von Agenten groß ist, wie beispielsweise in Kabelmodemsystemen, ist der manuelle Ansatz beschwerlich und lässt sich nicht gut skalieren. Demgemäß ist ein System und ein Verfahren sehr erwünscht, das ein sicheres Verfahren zum Eingeben der Geheimhaltungs- und Authentifikationsschlüssel in ein Kabelmodem in einem DOCSIS-System, um das Modem in eine SNMPv3-Betriebsart zu initialisieren, bereitstellen würde.
• ZUSAMMENFASSUNG DER ERFINDUNG
• Die vorliegende Erfindung richtet sich auf ein System und ein Verfahren zum Initialisieren eines SNMP-Agenten in eine SNMPv3-Betriebsart. In einem Aspekt der Erfindung ist ein Verfahren bereitgestellt, das einem Bediener ermöglicht, die anfänglichen Geheimhaltungs- und Authentifikations-SNMPv3-Schlüssel sicher in eine SNMPv3-Einrichtung einzugeben, und zu bewirken, dass die Einrichtung sich in eine SNMPv3-Betriebsart begibt. Sowohl der SNMP-Manager als auch der SNMP-Agent erzeugen eine zugehörige Zufallszahl und einen öffentlichen Wert. Der SNMP- Manager leitet seinen öffentlichen Wert in einer Konfigurationsdatei zu dem SNMP-Agenten weiter, was bewirkt, dass ein proprietäres MIB-Element in der SNMPv3-Einrichtung auf den öffentlichen Wert des SNMP-Managers gesetzt wird. Der SNMP-Manager liest den öffentlichen Wert des SNMP-Agenten durch eine SNMP-Anfrage unter Verwendung eines anfänglichen gültigen Anwenders, der Zugriff auf den öffentlichen Wert des SNMP-Agenten hat. Der SNMP-Agent und der SNMP-Manager berechnen jeweils unabhängig ein geteiltes Geheimnis unter Verwendung des Diffie-Hellman-Schlüsselaustauschprotokolls. Der SNMP-Manager und der SNMP-Agent wandeln jeweils unabhängig das geteilte Geheimnis in das gleiche lesbare Passwort um, wandeln das lesbare Passwort in den gleichen geheimen Schlüssel um und setzen dann den anfänglichen Authentifikationsschlüssel und den anfänglichen privaten Schlüssel auf den Wert des geheimen Schlüssels.
• In einem weiteren Aspekt der vorliegenden Erfindung leitet die Konfigurationsdatei den öffentlichen CMTS-Diffie-Hellman-Wert zu dem Modem unter Verwendung eines proprietären Konfigurationsdateiobjekttyps weiter, wobei das proprietäre Konfigurationsdateiobjekt den Vorteil aufweist, dass es nicht bewirkt, dass Nur-SNMP-v1/v2c-fähige Modems die Konfigurationsdatei zurückweisen, da sie kein Standard-SNMP-MIB-Objekt (Konfigurationsdatei-Element vom Typ 11) verstehen, das verwendet werden kann, um ein proprietäres MIB-Element in dem Modem zu setzen.
• KURZBESCHREIBUNG DER ZEICHNUNGEN
• 1 ist ein Blockdiagramm eines Systems zum Initialisieren eines SNMPv3-Agenten gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung; und
• 2 ist ein Flussdiagramm eines Verfahrens zum Initialisieren eines SNMPv3-Agenten gemäß einem Aspekt der vorliegenden Erfindung.
• DETAILLIERTE BESCHREIBUNG BEVORZUGTER AUSFÜHRUNSFORMEN
• Es sei angemerkt, dass die vorliegende Erfindung in verschiedenen Formen von Hardware, Software, Firmware, Spezialprozessoren oder einer Kombination aus diesen implementiert sein kann. Vorzugsweise ist die vorliegende Erfindung in Software als eine Anwendung implementiert, die Programmanweisungen umfasst, die konkret in einer oder mehreren Programmspeichereinrichtungen (zum Beispiel Diskette, RAM, CD ROM, ROM, Flash-Speicher, etc.) ausgeführt sind und durch jede Einrichtung, Maschine oder Plattform, die eine geeignete Architektur umfasst, ausführbar sind. Es sei weiter angemerkt, dass, da einige der Systemkomponenten und Verfahrensschritte vorzugsweise in Software implementiert sind, die tatsächlichen Verbindungen sich in Abhängigkeit von der Art und Weise, auf die die vorliegende Erfindung programmiert ist, unterscheiden können.
• In 1 zeigt ein Blockdiagramm ein System 10 zum Initialisieren einer SNMPv3-verwalteten Einrichtung gemäß einer beispielhaften Ausführungsform der vorliegenden Erfindung. Spezieller umfasst das System 10 ein DOCSIS-Kabelmodemsystem, das einen transparenten bidirektionalen Transfer von Internet Protokoll-(IP-)Paketen (über ein Backbone-Netzwerk 14, zum Beispiel das Internet, empfangen/übertragen) zwischen einem CMTS (cable modem termination system oder Kabelmodemabschlusssystem) 16 und einem SNMPv3-Kabelmodem 18 über ein vollständig koaxiales oder ein Hybridfaser-/Koaxial-(HFC-)Kabelnetzwerk 17 bereitstellt.
• Wie es in der Technik bekannt ist, führt das CMTS 16 Funktionen aus wie beispielsweise Bereitstellen einer Schnittstelle zwischen IP-Verkehr und HF-(Hochfrequenz-)Modulation/Übertragung der IP-Pakete und Zuordnen von IP-Adressen zu dem Kabelmodem 18. Es sei angemerkt, dass nur ein Kabelmodem zu Erläuterungszwecken gezeigt ist, dass das System 10 jedoch Hunderte von Kabelmodems umfassen kann.
• Das System 10 umfasst eine NMS (network management station oder Netzwerkverwaltungsstation) 11, die an dem Backbone-Netzwerk 14 angeordnet ist, um das CMTS 16 und das DOCSIS-Kabelmodem 18 zu verwalten. Die NMS 11 umfasst eine Anwenderschnittstelle 12 (z.B. eine GUI (Gaphic User Interface oder grafische Benutzerschnittstelle)) und einen SNMP-Manager 13 mit einer herkömmlichen Architektur zum Kommunizieren mit den SNMP-Agenten 19 des Kabelmodems 18 über SNMP-Nachrichten. Das System 10 umfasst des weiteren eine entfernte Servereinrichtung 15, auf die das Kabelmodem 18 zugreifen kann, um zum Beispiel eine Konfigurationsdatei herunterzuladen, die Parameter umfasst, die für ein Konfigurieren des Kabelmodems 18 verwendet werden. Zum Beispiel umfasst die Konfigurationsdatei, wie es nachstehend detailliert beschrieben ist, Objekte, die verwendet werden, um den SNMP-Agenten 19 in eine SNMPv3-Betriebsart unter Verwendung eines proprietären Diffie-Hellman-Schlüsselaustauschprotokolls zum Eingeben der anfänglichen Authentifikations- und Geheimhaltungs-(Privacy-)Schlüssel in das Kabelmodem 18 zu initialisieren. Im Allgemeinen ermöglicht dieses Protokoll einem Bediener an der NMS (Manager) 11, die anfänglichen Geheimhaltungs- und Authentifikations-SNMPv3-Schlüssel in das Modem 18 einzugeben, und zu bewirken, dass das Modem 18 sich unter Verwendung eines Diffie-Hellman-Schlüsselaustauschs in eine SNMPv3-Betriebsart begibt. Der Manager 13 stellt dem Modem 18 seinen öffentlichen Wert über die Konfigurationsdatei (zum Beispiel in dem Server 15 angeordnet) bereit.
• Der Manager 13 liest den öffentlichen Wert des Modems 18 über SNMPv3 unter Verwendung eines Standardvoreinstellungs-usmUser, der nur auf diese Werte (und die Standard-"System"-Gruppe) Zugriff hat. Über den DH-Austausch können der Manager 13 und das Kabelmodem 18 über ein gemeinsam geteiltes Geheimnis übereinkommen, das verwendet wird, um die Schlüsselwerte für einen anderen Standard-usmUser zu besetzen, der Zugriff auf die usmUserTable hat, um zusätzliche Anwender zu erzeugen und zu löschen. Der Manager 13 kann dann die Tabelle belegen, wie es notwendig ist.
• Gemäß der vorliegenden Erfindung umfasst das Kabelmodem 18 eine MIB, die ein proprietäres MIB-Modul und zugehörige MIB-Elemente umfasst, um einen Diffie-Hellman-Schlüsselaustausch auszuführen. Spezieller umfasst die MIB 20 ein proprietäres MIB-Modul, das hierin als TCE-DCM105-MIB bezeichnet ist, welches MIB-Elemente wie beispielsweise tceDCM105KickstartMyPublic- und tceDCM105KickstartMgrPublic-Objekte definiert, die für einen SNMPv3-Initialisierungsvorgang eingesetzt werden. Diese MIB-Elemente stellen einen Mechanismus für den SNMPv3-Agenten 19 (in dem Kabelmodem 18) und den SNMP-Manager 13 bereit, um einen Diffie-Hellman-Schlüsselaustausch auszuführen, und somit die privaten Schlüssel für den ersten gültigen Anwender in dem Kabelmodem 18 vorzusehen. Das tceDCM105KickstartMgrPublic-Objekt wird während eines Registrierungsvorgangs auf den öffentlichen Diffie-Hellman-Wert des Managers 13 gesetzt. Es gibt verschiedene Mechanismen, durch die der öffentliche Wert des Managers 13 zu dem Agenten transferiert wird. Vorzugsweise wird dieser Transfer über die Konfigurationsdatei (zum Beispiel in dem entfernten Server 15) ausgeführt, die durch das Kabelmodem 18 während des Kabelmodemregistrierungsvorgangs heruntergeladen wird. Der Wert des tceDCM105KickstartMyPublic-MIB-Elements umfasst den öffentlichen Diffie-Hellman-Wert des Agenten 19, den der Agent 19 für einen Zugriff durch den Manager 13 über das SNMP nach dem Registrierungsvorgang veröffentlicht. Vorzugsweise liest der Manager 13 den Inhalt von tceDCM105KickstartMyPublic unter Verwendung eines anfänglichen Anwenders, mit einem securityName, z.B. "docsisInit", ohne Authentifikation. Ein bevorzugter Initialisierungsvorgang wird nun weiter detailliert in Bezug auf das Flussdiagramm in 2 beschrieben.
• Das Flussdiagramm in 2 erläutert ein Verfahren zum Initialisieren eines SNMPv3-Agenten gemäß einem Aspekt der vorliegenden Erfindung. In 2 stellen Schritte 100–108 Schritte dar, die durch den SNMPv3-Agenten ausgeführt werden, und Schritte 200–208 stellen Schritte dar, die durch den Manager ausgeführt werden. Als Folge einer Initialisierung/eines Anschaltens des Kabelmodems bewirkt eine proprietäre Software, die in das Kabelmodem geladen wird, dass der SNMP-Agent einen SNMPv3-Anwender mit dem Namen "docsisInit" des Sicherheitslevels noAuthnoPriv erzeugt, und die geeigneten USM- und VACM-Einträge erzeugt (Schritt 100). Dieser anfängliche gültige Anwender (der von dem Manager verwendet wird, um z.B. auf das tceDCM105KickstartMyPublic-MIB-Element des Modems zuzugreifen) hat nur einen Lesezugriff auf die tceDCM105Kickstart group, die Systemgruppe und die nicht proprietären Traps. Als nächstes erzeugt der Agent eine Zufallszahl r₁ mit einer Länge von vorzugsweise bis zu 128 Bytes (Schritt 101). Dann wandelt der Agent unter Verwendung des weithin bekannten Diffie-Hellman-Protokolls seine Zufallszahl r₁ in einen öffentlichen Wert P₁ des Agenten um (Schritt 102). Spezieller ist der öffentliche Wert der Agenten

  

  wobei g die Basis von dem Satz von Diffie-Hellman-Parametern ist, p die Primzahl von diesen Parametern ist und r₁ eine ganze Zufallszahl ist, die durch den Agenten aus dem Intervall 2^(l-1) ≤ r1 < p – 1 ausgewählt wird, wobei l die Länge der privaten Zufallszahl r₁ in Bits ist. Der öffentliche Wert P₁ ist als ein OCTET STRING "PV" der Länge "k" ausgedrückt, der

  

  erfüllt, wobei PV₁, ..., PV_k die Oktetts von PV von dem ersten zu dem letzten sind, und wobei PV₁! = 0. Zusätzlich werden vorzugsweise die folgenden Diffie-Hellman-Parameter (Oakley group #2, RFC 2409, Abschn. 6.1, 6.2) verwendet:
  g = 2;
  p = FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CBB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF FFFFFFFF; und
  l = 64.
• Der Agent veröffentlicht seinen öffentlichen Wert P₁ in dem MIB-Element tceDCM105KickstartMyPublic (Schritt 103).
• Während einem Registrierungsvorgang erzeugt der SNMP-Manager seine Zufallszahl r₂, die vorzugsweise eine Länge von bis zu 128 Bytes aufweist (Schritt 200). Der Manager transformiert dann seine Zufallszahl r₂ in einen öffentlichen Wert P₂ unter Verwendung des Diffie-Hellman-Schlüsselaustauschprotokolls (Schritt 201) auf die gleiche Weise wie der Agent und unter Verwendung des gleichen Parametersatzes wie oben beschrieben.
• In dem DOCSIS-Framework versucht das Kabelmodem während einer Registrierung, wie es in der Technik bekannt ist, eine Connectivity durch zum Beispiel Übertragen einer DHCP-(dynamic host configuration proto col-)Anfrage zu dem CMTS herzustellen, um eine IP-Adresse und andere Parameter zu erhalten, die notwendig sind, um eine IP-Connectivity herzustellen. Das CMTS überträgt eine DHCP-Antwort, die zum Beispiel den Namen und Ort, zum Beispiel die IP-Adresse eines TFTP-(trivial file transfer protocol-)Servers (wie beispielsweise der entfernte Server 15 in 1), einer Konfigurationsdatei umfasst, auf die das Kabelmodem zugreifen kann. Unter Verwendung der Informationen in der DHCP-Antwort lädt das SNMPv3-Kabelmodem die geeignete Konfigurationsdatei über TFTP herunter.
• Gemäß der vorliegenden Erfindung transferiert der Manager seinen öffentlichen Wert P₂ zu dem Agenten über die Konfigurationsdatei (Schritt 202) (welche durch das Modem heruntergeladen wird) auf eine von mehreren Arten. In einer beispielhaften Ausführungsform, die in 2 erläutert ist, wird dies unter Verwendung eines SNMP-"Set"-MIB-Objekts in der Konfigurationsdatei (d.h. dem DOCSIS-Standardkonfigurationsdateielement vom Typ 11) ausgeführt, um das tceDCM105KickstacrtMgrPublic-MIB-Element (in dem Kabelmodem) auf den öffentlichen Wert P₂ des Managers zu setzen (Schritt 104). Andere Ausführungsformen zum Transferieren des öffentlichen Werts P₂ des Managers zu dem Kabelmodem sind nachstehend beschrieben.
• Wenn der Agent bestimmt, dass tceDCM105KickstartMgrPublic auf den öffentlichen Wert des Managers gesetzt wurde, berechnet der Agent ein geteiltes Geheimnis SK aus seiner Zufallszahl r₁ und dem öffentlichen Wert P₂ des Managers über das Diffie-Hellman-Schlüsselaustauschprotokoll (Schritt 105). Spezieller berechnet der SNMPv3-Agent das geteilte Geheimnis

  

  Mod p, wobei p die DH-Primzahl aus den bevorzugten gemeinsamen oben beschriebenen Parametern ist.
• Als nächstes wandelt der SNMPv3-Agent in einer bevorzugten Ausführungsform das geteilte Geheimnis SK in Geheimhaltungs- und Authentifikationsschlüssel um, wie folgt. Zuerst transformiert der Agent das geteilte Geheimnis SK in ein lesbares Passwort mit vorzugsweise 16 Zeichen (oder weniger) (Schritt 106). Vorzugsweise wird dies durch Wegstreichen von allen OCTETS (in dem SK String) über dem 16. Oktett und dann durch Ausführen des Folgenden an jedem übrigbleibenden Oktett ausgeführt:
• a. wenn (Oktett > 0 × 7F), dann Oktett = Oktett B 0 × 80; //Beseitige da oberste Bit
• b. wenn (Oktett ≤ 0 × 20) Oktett = Oktett + 0 × 40; //Ordne Steuercodes neu zu
• c. wenn (Oktett = 0 × 7F) Oktett = Oktett – 1;//Ordne Löschzeichen neu zu.
• Vorteilhafterweise ermöglicht dieser Vorgang des Erzeugens eines lesbaren Passworts einem Bediener an der NMS, das Passwort einfach einzugeben (entgegen dem Eingeben des Oktett-Strings des geteilten Geheimnisses).
• Zweitens wird das lesbare Passwort dann in einen 16 Byte-Schlüssel KC übersetzt (Schritt 107). Vorzugsweise wird dieser Schritt unter Verwendung des Algorithmus ausgeführt, der in Anhang A, Abschnitt A.1, Absatz (2) von RFC 2574 "A User-base Security Model (USM) for version 3 of the Simple Network Management Protocol" beschrieben ist. Spezieller wird ein String der Länge von 1 048 576 Oktetts durch Wiederholen des Werts des Passworts so oft wie notwendig, entsprechendes Kürzen, und Verwenden des sich ergebenden Strings als den Eingang in den Algorithmus MD5 (der in der Technik weithin bekannt ist) erzeugt, um einen Extrakt zu erzeugen (genannt "Digest 1"). Dann wird ein zweiter String durch Verknüpfen von Digest 1, dem SNMP-Maschinen-snmpEngineID-Wert, und dem Digest 1 gebildet. Dieser String wird als ein Eingang in den Algorithmus MD5 verwendet. Der sich ergebende Extrakt ist der 16-Byte-Schlüssel.
• Der SNMPv3-Agent erzeugt dann einen SNMPv3-Anwender (bereitgestellter Anwender), der hierin als "docsisProv" bezeichnet ist, und erzeugt geeignete USM- und VACM-Tabelleneinträge (wie es nachstehend ausführlich diskutiert ist) des Sicherheitslevels AuthPriv mit Lese-/Schreibzugriff auf die SNMPv3-Tabellen, und setzt dann vorzugsweise sowohl den Geheimhaltungsschlüssel als auch den Authentifikationsschlüssel (des bereitgestellten Anwenders) auf den Wert des 16-Byte-Schlüssels KC (Schritt 108). Der Agent verwendet diesen gleichen 16-Byte-Schlüssel KC für alle anderen Anwender, die in den SNMPv3-Tabellen durch die Konfigurationsdatei erzeugt werden. Dies beendet den Vorgang der Modemregistrierung.
• Auf einen Abschluss einer Registrierung hin kann der Manager durch Lesen eines OCTET STRING, der eine Länge von nicht Null aufweist (das heißt des öffentliche Werts P₁ des Agenten) aus dem tceDCM105KickstartMyPublic-MIB-Element bestätigen, dass sich das Modem in eine SNMPv3-Betriebsart begeben hat (Schritt 203). Der Manager liest diesen Wert unter Verwendung des anfänglichen Anwenders "docsisInit" (Sicherheitslevel noAuthNoPriv) über einen SNMP-"Get"-Befehl aus. Der Manager verwendet seine Zufallszahl r₂ und den öffentlichen Wert P₁ des Agenten (d.h. den Wert tceDCM105KickstartMyPublic), um das geteilte Geheimnis SK zu berechnen (über den Diffie-Hellman-Schlüsselaustauschalgorithmus) (Schritt 204). Dies ist das gleiche geteilte Geheimnis SK, das durch den Agenten berechnet wird. Als nächstes berechnet der Manager das gleiche lesbare Passwort für den "docsisProv"-Anwender aus dem geteilten Geheimnis SK (Schritt 205), und transformiert dann das lesbare Passwort in den Wert KC, wobei er den gleichen Vorgang ver wendet wie der Agent (oben in den Schritten 106–107 beschrieben) (Schritt 206). Der Manager setzt dann die Authentifikations- und Geheimhaltungsschlüssel für den bereitgestellten Anwender auf den Wert von KC (Schritt 207). Es sei angemerkt, dass der Diffie-Hellman-Schlüsselaustausch sicherstellt, dass sowohl der Agent als auch der Manager das gleiche 16-Zeichen-Passwort berechnen, ohne es preiszugeben. Es sei angemerkt, dass die Sicherheit dieses Ansatzes direkt mit der Stärke der Autorisierungssicherheit des Bereitstellens des öffentlichen Werts P₂ des Managers außerhalb eines Bands in Beziehung steht.
• Der Manager kann dann andere SNMPv3-Anwender durch Ändern der SNMPv3-Tabellen (d.h. Zugreifen auf die SNMP-USER-BASED-SM-MIB und die SNMP-VIEW-BASED-ACM-MIB) unter Verwendung des "docsisProv"-Anwenders und des Passworts für sowohl Authentifizierung als auch Geheimhaltung in dem AuthPriv-Sicherheitslevel erzeugen (Schritt 208).
• Das Folgende sind beispielhafte Einträge, die in den SNMPv3-USM- und VACM-Tabellen zum Initialisieren eines DOCSIS-Kabelmodems in eine SNMPv3-Betriebsart erzeugt werden. Spezieller werden die folgenden beispielhaften Einträge (1–4a, b, c) vorzugsweise in dem DOCSIS-SNMPv3-konformen Modem als Folge eines Anschaltens vorinstalliert und initialisiert:
• (1) Dieser Eintrag (usmUserEntry) in der usmUserTuble ermöglicht einen Zugriff auf das System und tceDCM105Kickstart groups. Dieser Eintrag ermöglicht dem SNMP-Manager, den öffentlichen Diffie-Hellman-Wert des Modems (der durch den Agenten in dem tceDCM105KickstartMyPublic-MIB-Element veröffentlicht ist) zu lesen, nachdem eine Registrierung abgeschlossen ist:

  usmUserEngineID	localEngineID
  usmUserName	"docsisInit"
  usmUserSecurityName	"docsisInit"
  usmUserCloneFrom	ZeroDotZero
  usmUserAuthProtocol	keines
  usmUserAuthKeyChange	""
  usmUserOwnAuthKeyChange	""
  usmUserPrivProtocol	keines
  usmUserPrivKeyChange	""
  usmUserOwnPrivKeyChange	""
  usmUserPublic	""
  usmUserStorageType	permanent
  usmUserStatus	aktiv

• (2) Ein Eintrag (vacmSecurityToGroupEntry) wird in der vacmSecurity-ToGroupTable erzeugt, um den anfänglichen Anwender "docsisInit" in den zugreifbaren Objekten zuzuordnen (d.h. dieser Eintrag erzeugt einen groupName für den anfänglichen Anwender "docsisInit", der verwendet wird, um eine Zugriffssteuerrichtlinie für den anfänglichen Anwender zu definieren):

  vacmSecurityModel	3 (USM)
  vacmSecurityName	"docsisInit"
  vacmGroupName	"docsisInit"
  vacmSecurityToGroupStorageType	permanent
  vacmSecurityToGroupStatus	aktiv.

• (3) Ein Eintrag (vacmAccessEntry), der in der vacmAccessTable erzeugt wird, übersetzt den groupName für den anfänglichen Anwender in einen geeigneten Sichtnamen (d.h. dieser Eintrag definiert die Zugriffsrechte für den anfänglichen Anwender "docsisInit"):

  vacmGroupName	"docsisInit"
  vacmAccessContextPrefix	""
  vacmAccessSecurityModel	3 (USM)
  vacmAccessSecurityLevel	noAuthNoPriv
  vacmAccessContextMatch	exakt
  vacmAccessReadViewName	"docsisInitRestricted"
  vacmAccessWriteViewName	""
  vacmAccessNotifyViewName	"docsisInitRestricted"
  vacmAccessStorageType	permanent
  vacmAccessStatus	aktiv

• Der obige Eintrag in der vacmAccessTable wird für einen nicht authentifizierten Zugriff verwendet, d.h. einen Lese-Melde-Zugriff für das securityModel USM, securityLevel "noAuthNoPriv" im Namen von securityName (d.h. Anwender "docsisInit"), der zu der Gruppe "docsisInit" auf die "docsisInitRestricted"-MIB-Ansicht in dem Voreinstellungskontext mit contextName"" gehört.
• (4) Die folgenden drei Einträge (vacmViewTreeFamilyEntry) werden in der vacmViewTreeFamilyTable erzeugt, um dem anfänglichen Eintrag zu ermöglichen, auf das System, Kickstart-Gruppen und generische Traps zuzugreifen:

  (a) vacmViewTreeFamiliyViewName	"docsisInitRestricted"
  vacmViewTreeFamiliySubtree	1.3.6.1.2.1.1 (System)
  vacmViewTreeFamiliyMask	""
  vacmViewTreeFamiliyType	1 (umfasst)

  vacmViewTreeFamiliyStorageType	permanent
  vacmViewTreeFamiliyStatus	aktiv
  (b) vacmViewTreeFamiliyViewName	"docsisInitRestricted"
  vacmVieuiTreeFamiliySubtree	(tceDCM105KickstartGroup)
  vacmViewTreeFamiliyMask	""
  vacmViewTreeFamiliyType	1 (umfasst)
  vacmViewTreeFamiliyStorageType	permanent
  vacmViewTreeFamiliyStatus	aktiv
  (c) vacmViewTreeFamiliyViewName	"docsisInitRestricted"
  vacmViewTreeFamiliySubtree	1.3.6.1.6.3.1.1.5 (snmpTraps)
  vacmViewTreeFamiliyMask	""
  vacmViewTreeFamiliyType	1
  vacmViewTreeFamiliyStorageType	permanent
  vacmViewTreeFamiliyStatus	aktiv

  Die folgenden Einträge (5–8a, b, c, d) werden in dem SNMPv3-konformen Modem erzeugt, wenn der Diffie-Hellman-Schlüsselaustausch abgeschlossen ist.
• (5) Der folgende Eintrag in die usmUserTable ist dem bereitgestellten Anwender zugeordnet, der mit den Authentifikations- und Geheimhaltungsschlüsseln erzeugt wird, die durch den DH-Schlüsselaustausch gesetzt werden. Dieser Eintrag wird vorzugsweise erzeugt, wenn das Modem korrekt über einen Eintrag des öffentlichen Werts des Managers in das Modem über die Konfigurationsdatei versorgt wird, wie es oben beschrieben ist (Schritt 202. 104 in 2). Es sei angemerkt, dass der userName "docsisProv" mindestens einen vollständigen Zugriff auf die usmUserTable für den erzeugten zusätzlichen gültigen Anwender bereitstellt: und wird vorzugsweise mit den Authentifikations- und Geheimhaltungsschlüsseln erzeugt, die durch DH-Schlüsselaustausch gesetzt werden:

  usmUserEngineID	localEngineID
  usmUserName	"docsisProv"
  usmUserSecurityName	"docsisProv"
  usmUserCloneFrom	ZeroDotZero
  usmUserAuthProtocol	usmHMACMD5AuthProtocol
  usmUserAuthKeyChange	""
  usmUserOwnAuthKeyChange	""
  usmUserPrivProtocol	usmDESPrivProtocol
  usmUserPrivKeyChange	""
  usmUserOwnPrivKeyChange	""
  usmUserPublic	""
  usmUserStorageType	permanent
  usmUserStatus	aktiv

• (6) Der nächste Eintrag bildet den bereitgestellten Anwender "docsisProv" in den zugreifbaren Objekten ab:

  vacmSecurityModel	3 (USM)
  vacmSecurityName	"docsisProv"
  vacmGroupName	"docsisProv"
  vacmSecurityToGroupStorageType	permanent
  vacmSecurityToGroupStatus	aktiv

• (7) Der nächste Eintrag übersetzt den groupName für den bereitgestellten Anwender in einen Sichtnamen: Anwender.

  vacmGroupName	"docsisProv"
  vacmAccessContextPrefix	""
  vacmAccessSecurityModel	3 (USM)
  vacmAccessSecurityLevel	AuthPriv
  vacmAccessContextMatch	exakt
  vacmAccessReadViewName	"docsisProv"
  vacmAccessWriteViewName	"docsisProv"
  vacmAccessNotifyViewName	"docsisProv"
  vacmAccessStorageType	permanent
  vacmAccessStatus	aktiv

• (8) Die folgenden vier Einträge ermöglichen dem bereitgestellten Anwender einen Lese-Schreib-Zugriff auf das System, tceDCM105Kickstart, usmMIB-Objects und vacmMIBObjects-Gruppen:

  (a) vacmViewTreeFamiliyViewName	"docsisProv"
  vacmViewTreeFamiliySubtree	1.3.6.1.2.1.1 (System)
  vacmViewTreeFamiliyMask	""
  vacmViewTreeFamiliyType	1
  vacmViewTreeFamiliyStorageType	permanent
  vacmViewTreeFamiliyStatus	aktiv
  (b) vacmViewTreeFamiliyViewName	"docsisProv"
  vacmViewTreeFamiliySubtree	1.6.3.1.6.3.15.1(usmMIBObjects)
  vacmViewTreeFamiliyMask	""
  vacmViewTreeFamiliyType	1
  vacmViewTreeFamiliyStorageType	permanent
  vacmViewTreeFamiliyStatus	aktiv

  (c) vacmViewTreeFamiliyViewName	"docsisProv"
  vacmViewTreeFamiliySubtree	1.6.3.1.6.3.16.1 (vacmMIBOjects)
  vacmViewTreeFamiliyMask	""
  vacmViewTreeFamiliyType	1
  vacmViewTreeFamiliyStorageType	permanent
  vacmViewTreeFamiliyStatus	aktiv
  (4) vacmViewTreeFamiliyViewName	"docsisProv"
  vacmViewTreeFamiliySubtree	(tceDCM 105KickstartGroup)\
  vacmViewTreeFamiliyMask	""
  vacmViewTreeFamiliyType	1
  vacmViewTreeFamiliyStorageType	permanent
  vacmViewTreeFamiliyStatus	aktiv

• In alternativen Ausführungsformen der vorliegenden Erfindung können andere Verfahren verwendet werden, um den öffentlichen Diffie-Hellman-Wert des Managers in das Modem einzugeben, und es in eine SNMPv3-Betriebsart zu bringen, unter Verwendung von proprietären Konfigurationsdateielementen (mit Ausnahme von einem Verwenden eines SNMP MIB-Objekts (Konfigurationsdateielement vom Typ 11), um das tceDCM105KickstartMgrPublic-MIB-Element zu setzen, wie es oben beschrieben ist). Diese proprietären Elemente sind insbesondere nützlich, um ein SNMPv3-konformes Modem in einem SNMP-Netzwerk zu initialisieren, das nur SNMPv1/v2c-Modems aufweist, die nicht in der Lage sind, eine Konfigurationsdatei, die SNMP-Sätze enthält, zu dem tceDCM105KickstartMgrPublic-Element zu verarbeiten, und folglich bewirken, dass die SNMPv1/v2c-Modems die Konfigurationsdatei zurückweisen. Zum Beispiel können die folgenden Konfigurationsdateielemente verwendet werden:
• (1) tceKickStartMgrPublic (Element 180) – Dieses Element umfasst einen Oktett-String mit einer Länge von bis zu 128 Bytes mit dem öffentlichen Wert des Managers; und
• (2) tceKickStartMgrPublic2 (Element 181) – Diese Konfigurationsdatei umfasst auch den öffentlichen Wert des Managers. Allerdings bewirkt es zusätzlich zu dem Bringen des Modems in eine SNMPv3-Betriebsart, dass das Modem die Inhalte einer docsDevNmAccessTable (die verwendet wird, um einen Zugriff in SNMPv1/v2c zu steuern) in entsprechende Einträge in den SNMPv3-Anwender-, Gruppen-, Zugriffs- und Ansichttabellen übersetzt. Spezieller wird für jeden Eintrag in der docsDevNmAcessTable ein Anwender und eine Ansicht mit einem userName, der auf den Wert in dem Gemeinschaftsstring gesetzt ist, und einem Zugriffstabelleneintrag, der ein noAuthNoPriv-Sicherheitslevel erfordert, erzeugt. Es werden auch Einträge in der SNMPv3 NOTIFICATION-MIB gemacht, um zu bewirken, dass Traps zu allen Trap-Empfängern gesendet werden, die in der docsDevNmAccessTable bezeichnet sind. Durch Verwenden dieses Konfigurationsdateielements (181) wird das Modem in eine SNMPv3-Betriebsart versetzt und der SNMPv2-Manger kann immer noch darauf zugreifen. Details dieses Konfigurationsdateielements und des zugehörigen Übersetzungsvorgangs sind in der PCT-Patentanmeldung "System and Method For Simple Network Management Protocol (SNMP) v3 Modems to Interoperate with SNMPv1/v2c Modems", Anwaltsaktenzeichen Nr. RCA 89827, die gleichzeitig hiermit eingereicht wurde, beschrieben.
• In einer weiteren Ausführungsform können die öffentlichen Werte P₁ und P₂ des Agenten und des Managers unter Verwendung des DHCP ausgetauscht werden. Zum Beispiel kann der Agent seinen öffentlichen Wert in der DHCP-Anfrage umfassen, die während des Initialisierungsvorgangs (wie oben beschrieben) zu dem CMTS übertragen wird, und der öffentliche Wert des Managers kann zu dem Kabelmodem in der zugehörigen DHCP- Antwort übertragen werden. Insbesondere kann das folgende proprietäre DHCP-Element tceDHCPKickstartMgrPublic (182) in der DHCP-Antwort enthalten sein.

Claims (5)

1. Verfahren zum Initialisieren einer SNMP simple network management protocol v3-Einrichtung, wobei ein SNMP-Manager und ein SNMP-Agent in der SNMPv3-Einrichtung ein Diffie-Hellman-Schlüsselaustauschprotokoll verwenden, um einen anfänglichen Geheimhaltungsschlüssel und einen anfänglichen Authentifikationsschlüssel in die SNMPv3-Einrichtung einzugeben, wobei der SNMP-Manager und der SNMP-Agent beide eine zugehörige Zufallszahl und einen öffentlichen Wert erzeugen (101, 102, 200, 201), wobei der SNMP-Manager seinen öffentlichen Wert in einer Konfigurationsdatei an den SNMP-Agenten weiterleitet, wobei der SNMP-Manager den öffentlichen Wert des SNMP-Agenten durch eine SNMP-Anfrage unter Verwendung eines anfänglichen gültigen Anwenders, der einen Zugriff auf den öffentlichen Wert des SNMP-Agenten hat, liest (203), und wobei der SNMP-Agent und der SNMP-Manager ein geteiltes Geheimnis unter Verwendung des Diffie-Hellman-Schlüsselaustauschprotokolls berechnen (105, 204), wobei das Verfahren durch die Schritte gekennzeichnet ist: Umwandeln des geteilten Geheimnisses in ein lesbares Passwort (106, 205); Umwandeln des lesbaren Passworts in einen geheimen Schlüssel (107, 206); und Setzen des anfänglichen Authentifikationsschlüssels und des anfänglichen Geheimhaltungsschlüssels auf den Wert des geheimen Schlüssels (108, 207).
2. Verfahren nach Anspruch 1, wobei das lesbare Passwort ein 16-Zeichen-Passwort umfasst.
3. Verfahren nach Anspruch 1, wobei der geheime Schlüssel einen 16-Byte-String umfasst.
4. Verfahren nach Anspruch 1, des weiteren dadurch gekennzeichnet, dass die Konfigurationsdatei ein proprietäres Konfigurationsdateielement zum Weiterleiten des öffentlichen Werts des SNMP-Managers zu dem SNMP-Agenten umfasst.
5. Verfahren nach Anspruch 4, wobei die SNMPv3-Einrichtung in einem SNMPv1/v2c-fähigen Netzwerk arbeitet, das eine SNMPv2c-Einrichtung umfasst, und wobei das proprietäre Konfigurationsdateielement von der SNMPv2c-Einrichtung ignoriert wird.