DE60115672T2

DE60115672T2 - Sicherheitsarchitektur der internet-protokoll telefonie

Info

Publication number: DE60115672T2
Application number: DE60115672T
Authority: DE
Inventors: Sasha Medvinsky
Original assignee: Arris Technology Inc; General Instrument Corp
Current assignee: Arris Technology Inc
Priority date: 2000-09-22
Filing date: 2001-09-21
Publication date: 2006-07-20
Anticipated expiration: 2021-09-22
Also published as: KR20040014400A; CN1476709A; ATE312464T1; AU2001292955A1; DE60115672D1; CN1285202C; EP1320975B1; CA2421628A1; WO2002025899A1; JP2004509567A; EP1320975A1

Description

Diese Anmeldung beansprucht Priorität gegenüber der gleichzeitig anhängigen PCT-Anmeldung Nr. PCT/US00/09318, eingereicht am 7. April 2000 mit dem Titel „Built-in Manufacturer's Certificates for a Cable Telephony Adapter to Provide Device and Service Certification", die Priorität gegenüber der US Anmeldung Nr. 60/128,772 mit dem Titel „Internet Protocol Telephony Security Architecture", eingereicht am 9. April 1999, sowie der PCT-Anmeldung Nr. PCT/US00/02174, eingereicht am 28. Januar 2000 mit dem Titel „Key Management for Telephone Calls to Protect Signaling and Call Packets Between CTA's" beansprucht.
HINTERGRUND
Diese Erfindung bezieht sich im Allgemeinen auf Netzsicherheit, und insbesondere auf ein System zum Bereitstellen von Schlüsselverwaltung zwischen einem Server und einem Client, z.B. in einem Telefonie- oder einem Internettelefonie-Netz.
In Netzen, die ihre Grundlage auf einer Client-/Serverkonfiguration haben, besteht ein Bedarf daran, einen sicheren Kanal zwischen dem Server und den Clients zu etablieren. US-A-6,058,480 offenbart ein System, in dem ein Server bereitgestellt ist, ein Client, der konfiguriert ist, um an den Server verkoppelt zu werden, und in dem des Weiteren eine vertrauenswürdige dritte Partei existiert, die an den Client verkoppelt ist, der innerhalb des Netzes Schlüsselverwaltung betreibt. Zusätzlich dazu besteht in Netzen, die eine dritte Partei benutzen, um eine Vertrauensstellung zu zertifizieren, Bedarf daran, einen effizienten Mechanismus bereitzustellen, der ermöglicht, dass eine Schlüsselverwaltungsnachricht durch den Server initiiert wird.
In solchen Netzen, die eine vertrauenswürdige dritte Partei für den Server und den Client benutzen, kann der Client typischerweise ein verschlüsseltes Authentifizierungszeichen von der vertrauenswürdigen dritten Partei anfordern, das verwendet werden kann, um Schlüsselverwaltung mit dem spezifizierten Server zu initiieren; der Server wird jedoch typischerweise die Schlüsselverwaltungssitzung direkt mit dem Client initiieren. Es ist weniger wünschenswert, dass der Server verschlüsselte Authentifizierungszeichen für jeden der Clients von der vertrauenswürdigen dritten Partei erhält. Ein derartiger Ansatz würde einem Server ein Overhead zu hinzufügen, was von ihm erfordern würde, einen kryptographischen Zustand für jeden der Clients aufrechtzuerhalten. Sollte ein solcher Server versagen, müsste ein Backup-Server einer Rückstellprozedur unterzogen werden, in der er neue Authentifizierungszeichen für jeden der Clients erhalten müsste. Die Clients müssen während ihrer Versorgungsphase initialisiert werden, um ihnen zu ermöglichen, eine vertrauenswürdige dritte Partei erfolgreich zu authentifizieren und die verschlüsselten Authentifizierungszeichen zu erhalten. Ein vorgeschlagenes Verfahren zur Clientinitialisierung ist in der PCT-Anmeldung Nr. PCT/US00/09318 mit dem Titel „BUILT-IN MANUFACTURER'S CERTIFICATES FOR A CABLE TELEPHONY ADAPTER TO PROVIDE DEVICE AND SERVICE CERTIFICATION" offenbart. Dennoch besteht Bedarf daran, einen effizienten Mechanismus bereitzustellen, durch den der Server die Schlüsselverwaltungssitzung mit dem Client initiieren kann, im Gegensatz zu einem System, in dem nur der Client eine solche Sitzung initiieren kann.
Ein solches Client-/Servernetz ist das Client-/Servernetz, das in der Internettelefonie existiert. Bei Internettelefonie-Systemen kann eine Kabeltelefonieadapter-Vorrichtung ((CTA)-Vorrichtung) verwendet werden, um einem Benutzer das Senden und Empfangen von Informationen in sicheren Transaktionen über ein Internettelefonie-Netz zu ermöglichen. Bei typischem Betrieb wird eine Reihe von Kennzeichenblöcken ausgetauscht, die die CTA-Vorrichtung mit dem Internettelefonie-Netz registrieren, bevor ein sicherer Kanal mit einem anderen Benutzer etabliert werden kann. Die CTA-Vorrichtung muss daher durch das Internettelefonie-System authentifiziert werden. Ansonsten wäre der Prozess offen für DoS-Angriffe (Dienstverweigerungsangriffe) – da einige der Versorgungsaustausche gefälscht sein können. Zusätzlich dazu ist es für den Dienstanbieter wünschenswert, die CTA-Vorrichtung zu identifizieren – um sicherzustellen, dass nur autorisierte Vorrichtungen in ihrem Internettelefonie-Netz erlaubt sind.
ZUSAMMENFASSUNG DER ERFINDUNG
Die Erfindung stellt gemäß Anspruch 1 und 16 ein Verfahren und ein System zum Bereitstellen von Schlüsselverwaltung in einem Client-/Servernetz bereit.
Zusätzlich dazu kann eine Ausführungsform in Code und durch Schaltungsanordnung implementiert werden, die betriebsfähig ist, um die Vorgänge des Verfahrens herzustellen.
Ein besseres Verständnis der Art der hier offenbarten Erfindungen wird unter Bezugnahme auf die verbleibenden Abschnitte der Beschreibung und die beigefügten Zeichnungen realisiert.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 zeigt ein Flussdiagramm, das eine Übersicht über eine Ausführungsform der Erfindung darstellt.
2A und 2B zeigen ein detaillierteres Flussdiagramm, das eine Schlüsselverwaltungssitzung zwischen einem Server und einem Client darstellt.
3 zeigt Schritte einer Schlüsselverwaltungssitzung, nachdem die Schlüsselverwaltungssitzung initiiert worden ist.
4 zeigt ein allgemeines Blockdiagramm eines Netzes für Client/Server/vertrauenswürdige dritte Partei.
5 zeigt ein Blockdiagramm eines Internettelefonie-Netzes, in dem ein Kabeltelefonieadapter, ein Signalisierungssteuergerät und ein Schlüsselverteilungszentrum miteinander verkoppelt sind.
6 zeigt die Implementierung der Datenstrukturen zum Etablieren einer Schlüsselverwaltungssitzung wie durch eine Ausführungsform der Erfindung implementiert.
BESCHREIBUNG DER SPEZIFISCHEN AUSFÜHRUNGSFORMEN
1 zeigt ein Flussdiagramm, das eine Übersicht über eine Ausführungsform der Erfindung darstellt. Im Flussdiagramm 100 ist ein Server bereitgestellt 104, und ein an den Server verkoppelter Client ist ebenfalls bereitgestellt 108. Es wird für den Server und den Client eine vertrauenswürdige dritte Partei bereitgestellt 112, und dem Server wird ermöglicht, durch die Benutzung einer Nonce 116 eine Schlüsselverwaltungssitzung mit dem Client zu initiieren.
Es versteht sich, dass ein Server ein gemeinsam genutzter Rechner in einem Netz ist, wie beispielsweise ein in einem Internettelefonie-Netz verwendetes Signalisierungssteuergerät. Des Weiteren versteht es sich, dass ein Client ein Computer oder eine Vorrichtung ist, die durch eine andere Netzrechenvorrichtung wie beispielsweise einen Kabeltelefonieadapter (Client), der über ein Internettelefonie-System durch ein Signalisierungssteuergerät (Server) bedient wird, bedient wird. Zusätzlich dazu versteht es sich, dass eine vertrauenswürdige dritte Partei für den Server oder den Client eine Vorrichtung oder ein Computer ist, die/der von mindestens zwei Parteien benutzt wird, die/der kryptographische Prozesse wie etwa das Zertifizieren der Identität einer der zwei Parteien an die andere erleichtert. Letztlich versteht es sich, dass eine Nonce eine erzeugte Nummer ist, die nur einmal benutzt wird. Die Verwendung einer Nonce hilft dabei, einen Angreifer vom Implementieren eines Angriffs mit Aufzeichnungswiederholung abzuhalten. Eine solche Nonce kann zufällig erzeugt werden.
Das Verfahren aus 1 kann besser unter Bezugnahme auf 2A und 2B verstanden werden. In dem in 2A und 2B als 200 bezeichneten Verfahren ist ein Server wie beispielsweise ein Signalisierungssteuergerät in einem Internettelefonie-System bereitgestellt 204. Zusätzlich dazu ist ebenfalls ein Client wie beispielsweise ein Kabeltelefonieadapter in einem Internettelefonie-System bereitgestellt 208. Eine vertrauenswürdige dritte Partei für den Client und den Server wie beispielsweise ein Schlüsselverteilungszentrum in einem Internettelefonie-System ist auch bereitgestellt 212. Der Server, der Client und die vertrauenswürdige dritte Partei sind miteinander verkoppelt. Der Client initiiert typischerweise Schlüsselverwaltungssitzungen mit dem Server. Es kommt jedoch auch vor, dass der Server eine Schlüsselverwaltungssitzung mit dem Client initiieren muss. Anstatt die Triggernachricht zu authentifizieren (z.B. mit einer digitalen Signatur und einem digitalen Zertifikat), kann die Erfindung bei der Authentifizierung der nachfolgenden AP-Aufforderungsnachricht von dem Client eine Nonce benutzen. Diese Ausführungsform der Erfindung hält einen Gegner (der einen rechtmäßigen Server verkörpert) nicht davon ab, eine rechtswidrige Triggernachricht an den Client zu schicken und diesen dazu zu verleiten, mit einer AP-Aufforderung zu antworten. Stattdessen sorgt sie dafür, dass eine derartige AP-Aufforderung von dem rechtmäßigen Server zurückgewiesen wird. Dieser Mechanismus ist entworfen, um das Overhead des Servers des Initiierens von Schlüsselverwaltungsaustauschen mit seinen Clients zu reduzieren, wobei immer noch ausreichend Sicherheit aufrechterhalten wird. Folglich wird bei 216 eine Triggernachricht an dem Server erzeugt, um eine Schlüsselverwaltungssitzung zu initiieren. Dann wird eine Nonce an dem Server 220 erzeugt, und die Nonce und die Triggernachricht werden miteinander verkoppelt und an den Client 224 übermittelt. Der Client empfängt die Triggernachricht und die Nonce 228. Dann bezeichnet der Client die Nonce als eine returned_nonce 232. Auf diese Weise kann der Client die empfangene Nonce an den Server zurückschicken, um nachzuweisen, dass die Nachricht von dem Client ist. Bei 236 wird eine zweite Nonce an dem Client erzeugt. Die zweite Nonce ist für den Gebrauch durch den Server und den Client als Teil der Schlüsselverwaltungssitzung, die initiiert wird. Der Client erzeugt eine Antwortnachricht auf die Triggernachricht, die von dem Server 240 empfangen wurde. Dann werden die Antwortnachricht, die returned_nonce und die second_nonce an den Server 244 übermittelt:
An dem Server wird ein Wert außerhalb der Begrenzung (out-of-boundsvalue) für die returned_nonce bestimmt, und der Wert der returned_nonce wird mit dem Wert der Nonce, die an dem Server erzeugt wurde, und mit dem Wert außerhalb der Begrenzung verglichen. Wenn die Werte der returned_nonce und der an dem Server gespeicherten Nonce gleichwertig sind, kann die Schlüsselverwaltungssitzung fortfahren.
Wenn jedoch der Wert der returned_nonce nicht dem Wert der an dem Server gespeicherten Nonce entspricht, wird eine Bestimmung vorgenommen, dass die returned_nonce sogar eine falsche Nonce 252 ist. In einem solchen Fall besteht die Möglichkeit, dass das Signal korrumpiert worden ist; oder es besteht eine Möglichkeit, dass ein Angreifer versucht, einen Angriff auf den Dienst zu initiieren. Bei einem Angriff auf den Dienst versucht der Angreifer, auf betrügerische Weise eine neue Verschlüsselungssitzung zu initiieren, um zu bewirken, dass der Server Prozessorzyklen benutzt, die verhindern, dass der Prozessor diese Zyklen für andere Vorgänge benutzt. Der Server würde also unter einem solchen Angriff weniger effektiv sein, als er unter normalen Bedingungen wäre. Durch das Wiederholen eines solchen Angriffs kann ein Angreifer verhindern, dass der Server effektiv betrieben wird und kann so den Betrieb des hierarchischen Netzes, wie beispielsweise eines Internettelefonie-Netzes, beeinträchtigen. Wenn bestimmt wird, dass die returned_nonce nicht gleichwertig zu dem Wert der an dem Server gespeicherten Nonce ist, wird die mit der returned_nonce gesendete Antwortnachricht als nicht authentifiziert 256 ignoriert. Wenn die returned_nonce jedoch dem Wert der an dem Server gespeicherten Nonce entspricht, dann fährt die Schlüsselverwaltungssitzung fort 260.
3 zeigt zusätzliche Schritte in einer typischen Schlüsselverwaltungssitzung, wie durch Block 260 in 2B hervorgehoben. In 3 zeigt das Verfahren 300, dass von dem Server eine Anwendungs-ANTWORT (AP-Antwort) erzeugt 364 wird. Die AP-ANTWORT wird mit der zweiten Nonce, die durch den Client 368 erzeugt wurde, an den Client übermittelt. Die AP-Aufforderung ist eine Abkürzung für Anmeldungsaufforderung, und AP-Antwort steht für Anmeldungsantwort. Diese zwei Nachrichten können zum Beispiel durch den Kerberos-Schlüsselverwaltungsstandard (siehe IETF RFC 1510) spezifiziert werden. Als ein weiteres Beispiel kann im Zusammenhang mit Kerberos die zweite Notiz die Zeit des Clients, ausgedrückt in Mikrosekunden, sein. Wenn die AP-ANTWORT und die zweite Nonce an dem Client empfangen werden, überträgt der Client eine wiedergewonnene Sicherheitsassoziations-Nachricht((SA)-Nachricht) an den Server 372. Dies vervollständigt die anwendbare Kerberos-Schlüsselverwaltungssitzung.
4 zeigt ein Blockdiagramm eines Netzes für Client/Server/vertrauenswürdige dritte Partei. Ein Client 401 ist mit einem Server 402 verkoppelt. Zusätzlich dazu ist der Client mit einer vertrauenswürdigen dritten Partei 404 verkoppelt. Die vertrauenswürdige dritte Partei ist ebenfalls mit dem Server 402 verkoppelt. 4 stellt folglich das Netz dar, in dem eine Ausführungsform der Erfindung implementiert werden kann.
In 5 wird ein Internettelefonie-Netz dargestellt, das eine Ausführungsform der Erfindung implementiert. Ein Client wie beispielsweise ein Kabeltelefonieadapter 501 ist mit einem Server, wie beispielsweise einem Signalisierungssteuergerät 502, verkoppelt. Des Weiteren sind der Kabeltelefonieadapter und das Signalisierungssteuergerät ebenfalls mit einer vertrauenswürdigen dritten Partei, die als Schlüsselverteilungszentrum 504 dargestellt ist, verkoppelt. Des Weiteren ist das Signalisierungssteuergerät mit dem Internetprotokolltelefonie-Netz 508 verkoppelt. Ein solches Netz wie das in 5 dargestellte wäre nützlich zum Etablieren eines Internetprotokolltelefonie-Anrufs von einem Benutzer, der durch das Internetprotokolltelefonie-Netz 508 an den Kabeltelefonieadapter mit einem anderen Benutzer, der mit einem ähnlichen Netz verbunden ist, gekoppelt ist. Der Benutzer kann folglich durch den Kabeltelefonieadapter und das Signalisierungssteuergerät als anrufende Partei authentifiziert werden, wenn der Anruf über das Internetprotokolltelefonie-Netz vermittelt wird. Weitere Einzelheiten eines derartigen Netzes sind in den Referenzen dargestellt, die unter Bezugnahme eingeschlossen wurden.
6 stellt Datenstrukturen zum Implementieren einer Kerberos-Schlüsselverwaltungssitzung, die durch einen Server in einem Client/Server-Netz initiiert wird, dar. In 6 wird eine Nonce Nummer 1 mit einem Initiierungssignal wie beispielsweise einer Trigger- oder einer Reaktivierungsnachricht verkoppelt, und die kombinierte Nachricht wird über eine Schnittstelle 601 an den Client übertragen. Der Client speichert Nonce Nummer 1. Er fügt dann Nonce Nummer 2 und eine Anmeldungsaufforderung (AP-Aufforderung) in der Datenstruktur wie der in 6 gezeigten hinzu. Dieser Satz Daten wird dann über die Schnittstelle hinweg zurück an den Server übertragen. Der Server vergleicht den Wert der empfangenen Nonce Nummer 1 mit dem Wert der an dem Server gespeicherten Nonce Nummer 1, um die Authentizität der AP-Aufforderung zu bestätigen. Beim Authentifizieren der AP-Aufforderung erzeugt der Server eine AP-Antwort und verkoppelt sie mit Nonce Nummer 2, die durch den Client erzeugt wurde. Die kombinierte Nonce Nummer 2 und die AP-Antwort werden dann über die Schnittstelle hinweg an den Client übertragen. Der Client kann die Authentizität der AP-Antwort durch das Vergleichen des Werts der Nonce Nummer 2, die von dem Server mit dem Wert der an dem Client gespeicherten Nonce Nummer 2 empfangen wurde, verifizieren. Beim Authentifizieren der AP-Antwort erzeugt der Client eine wiedergewonnene Sicherheitsassoziations-Nachricht ((SA)-Nachricht) und überträgt diese über die Schnittstelle hinweg an den Server. Dieses auf Kerberos basierende Schlüsselverwaltungsprotokoll wird hierdurch auf eine effiziente Weise implementiert und ermöglicht dem Server des Weiteren, die Schlüsselverwaltungssitzung unter Verwendung von nur einer zusätzlichen Nonce als Overhead an die Initiierungsnachricht zu initiieren. Das Verfahren ist folglich dahingehend hoch effizient, dass nur eine Nonce beim Authentifizierungsprozess der Initiierungsnachricht verwendet werden muss.
Zusätzlich zu Ausführungsformen, bei denen die Erfindung durch Hardware erreicht wird, sei somit auch bemerkt, dass diese Ausführungsformen durch den Gebrauch eines Manufakturerzeugnisses erreicht werden können, das ein maschinennutzbares Medium mit einem darin ausgeführten maschinenlesbaren Programmcode, der die Aktivierung der in dieser Beschreibung offenbarten Funktionen und/oder Fertigung der Hardware bewirkt, umfasst. Dies kann zum Beispiel durch die Verwendung von Hardware-Beschreibungssprache (HDL = hardware description language), Register-Transfer-Sprache (RTL = register transfer language), VERILOG, VHDL oder ähnlichen Programmierwerkzeugen, wie sie der durchschnittliche Fachmann verstehen würde, erreicht werden. Das Buch „A Verilog HDL Primer" von J. Bhasker, Star Galaxy Pr., 1997, liefert nähere Informationen zu Verilog und HDL. Es ist daher vorgesehen, dass die wie oben beschriebenen, durch die vorliegende Erfindung erreichten Funktionen in einem Kern repräsentiert sein könnten, der beim Programmierungscode benutzt und als Teil der Herstellung integrierter Schaltkreise in Hardware umgewandelt werden könnte. Es ist daher wünschenswert, dass die oben geschilderten Ausführungsformen mit ihrem Programmcodemittel ebenfalls als durch dieses Patent auch geschützt betrachtet werden.
Es sei bemerkt, dass die Ausführungsformen der Erfindung durch die Verwendung eines elektrischen Signals wie beispielsweise eines Computerdatensignals, das in einer Trägerwelle verkörpert ist, erzielt werden könnten, um die relevanten Signale an einen Empfänger zu übermitteln. Wo daher Code als auf einem Computermedium gespeichert dargestellt wird, sollte er auch als ein elektrisches Signal übermittelbar sein. Wenn eine Datenstruktur für eine Nachricht dargestellt wird, sollte es auf ähnliche Weise auch klar sein, dass sie in ein elektrisches Signal zur Übertragung über ein Medium wie beispielsweise das Internet verkörpert werden kann.
Es sei auch angemerkt, dass viele der hierin vorgetragenen Strukturen und Vorgänge als Mittel zur Durchführung einer Funktion bzw. als Schritte zur Durchführung einer Funktion vorgetragen werden können. Daher versteht es sich, dass eine derartige Sprache berechtigt ist, alle derartigen Strukturen oder Vorgänge, die innerhalb dieser Beschreibung und ihrer Entsprechungen offenbart werden, abzudecken, einschließlich der unter Bezugnahme aufgeführten Materie.

Claims

Ein Verfahren zum Bereitstellen von Schlüsselverwaltung, das Folgendes umfasst: Bereitstellen eines Servers (204); Bereitstellen eines Clients (208), der konfiguriert ist, um an den Server (204) verkoppelt zu werden; Bereitstellen einer vertrauenswürdigen dritten Partei (212), die konfiguriert ist, um an den Client (208) verkoppelt zu werden; gekennzeichnet durch: Erzeugen einer Triggernachricht an dem Server (216); Erzeugen einer Nonce an dem Server (220); Übermitteln der Triggernachricht und der Nonce an den Client (224); Empfangen der Triggernachricht und der Nonce an dem Client (228); und Bezeichnen einer Nonce als eine returned_nonce an dem Client (232); Erzeugen einer zweiten Nonce an dem Client (236); Erzeugen einer Antwortnachricht auf die Triggernachricht, die von dem Server (240) empfangen wurde; Übermitteln der Antwortnachricht, der returned_nonce und der second_nonce an den Server (244); Vergleichen des Werts der returned_nonce mit dem Wert der Nonce, die an dem Server (248) erzeugt wurde.
Verfahren wie in Anspruch 1 beschrieben, und das ferner Folgendes umfasst: Vorbestimmen eines Werts außerhalb der Begrenzung für die Nonce; Überprüfen der Nonce, um zu bestimmen, ob der Wert der Nonce der Wert außerhalb der Begrenzung ist.
Verfahren wie in Anspruch 1 beschrieben, und das ferner Folgendes umfasst: Bestätigen des Werts der returned_nonce an dem Server, und Übermitteln einer Antwortnachricht von dem Client an den Server.
Verfahren wie in einem der Ansprüche 1 bis 3 beschrieben, und das ferner Folgendes umfasst: Empfangen einer Antwortnachricht und einer false_nonce von dem Client an dem Server (252); Bestimmen, dass die false_nonce falsch ist; Ignorieren der Antwortnachricht (256) des Clientst.
Verfahren wie in Anspruch 1 beschrieben zur Verwendung in einem auf Kerberos basierenden System, wobei ein Schlüsselverteilungszentrum (504) konfiguriert ist, um als eine vertrauenswürdige dritte Partei zu wirken.
Verfahren wie in Anspruch 5 beschrieben, und das ferner Folgendes umfasst: Übermitteln der Triggernachricht und der Nonce an den Client (224), um eine Schlüsselverwaltungssitzung zwischen dem Server und dem Client zu initiieren.
Verfahren wie in Anspruch 6 beschrieben, und das ferner Folgendes umfasst: Empfangen der Triggernachricht und der Nonce an dem Client (228); Erzeugen einer Antwortnachricht auf die Triggernachricht; Übermitteln der Antwortnachricht und einer returned_nonce an den Server.
Verfahren wie in Anspruch 7 beschrieben, und das ferner Folgendes umfasst: Bestätigen des Werts der returned_nonce an dem Server, und dann das Fortfahren mit der Schlüsselverwaltungssitzung.
Verfahren wie in Anspruch 5 beschrieben, und das ferner Folgendes umfasst: Empfangen einer Antwortnachricht und einer false_nonce von dem Client (252) an dem Server; Bestimmen, dass die false_nonce nicht mit der Nonce (256) übereinstimmt; Bestimmen, dass der Server die Schlüsselverwaltungssitzung nicht initiiert hat.
Verfahren wie in Anspruch 1 beschrieben für einen Kabeltelefonieadapter (CTA) (501) und ein Signalisierungssteuergerät (502) in einem Internettelefonie-Netz, wobei das Verfahren ferner Folgendes umfasst: Bereitstellen des Signalisierungssteuergeräts (502) als Server; Bereitstellen des CTA (501), der konfiguriert ist, um an das Signalisierungssteuergerät (502) als Client verkoppelt zu werden; Bereitstellen eines Schlüsselverteilungszentrums (KDC) (504); Erzeugen der Triggernachricht an dem Signalisierungssteuergerät; Erzeugen der Nonce an dem Signalisierungssteuergerät; Koppeln der Nonce mit der Triggernachricht; Übertragen der mit der Triggernachricht verkoppelten Nonce an das CTA; Erzeugen einer Antwortnachricht auf die Triggernachricht; Verwenden des Werts der Nonce als den Wert einer returned_nonce; Koppeln der Antwortnachricht mit der returned_nonce; Erzeugen einer second_nonce an dem Client; Übertragen der returned_nonce, second_nonce und der Antwortnachricht an das Signalisierungssteuergerät; Vergleichen der returned_nonce mit der Nonce; Übertragen einer AP-Antwort als Antwort auf die Antwortnachricht und die second_nonce; Übertragen einer wiedergewonnenen SA-Nachricht an das Signalisierungssteuergerät.
Verfahren wie in Anspruch 1 beschrieben zum Übermitteln eines Schlüssels von einem Server an einen Client, das ferner Folgendes umfasst: Erzeugen einer Reaktivierungsnachricht an dem Server; Erzeugen einer server_nonce an dem Server; Übermitteln der Reaktivierungsnachricht und der server_nonce an den Client; Erzeugen einer AP-Aufforderungsnachricht an dem Client; Erzeugen einer second_nonce an dem Client; Übermitteln einer client_nonce und der AP-Aufforderungsnachricht an den Server; und Bestätigen, dass die client_nonce, die mit der AP- Aufforderungsnachricht übermittelte second_nonce mit der an dem Server erzeugten server_nonce übereinstimmt.
Verfahren wie in Anspruch 1 beschrieben zum Bestätigen, dass eine durch einen Server von einem Client empfangene Nachricht durch den Server getriggert wurde, das ferner Folgendes umfasst: Empfangen einer AP-Aufforderungsnachricht von dem Client; Empfangen einer second_nonce von dem Client; Empfangen einer client_nonce von dem Client, wobei die client_nonce mit der AP-Aufforderung assoziiert wird; und Bestimmen, ob die client_nonce mit einer von dem Server übermittelten Nonce übereinstimmt.
Verfahren wie in Anspruch 12 beschrieben und das ferner Folgendes umfasst: Bestimmen, dass die client_nonce nicht mit der von dem Server übermittelten Nonce übereinstimmt; und Ignorieren der AP-Aufforderung.
Verfahren wie in Anspruch 13 beschrieben, und das ferner Folgendes umfasst: Warten an dem Client auf eine Antwort von dem Server auf die AP-Aufforderung; Abbrechen der AP-Aufforderungssitzung nach einem vorbestimmten Zeitraum, wenn keine Antwort von dem Server empfangen wird.
Verfahren wie in Anspruch 12 beschrieben, und das ferner Folgendes umfasst: Bestimmen, dass die client_nonce mit der von dem Server übermittelten Nonce übereinstimmt; und Erzeugen einer AP-Antwort an dem Server auf die AP-Aufforderung.
Ein System zum Bereitstellen von Schlüsselverwaltung in einem auf Kerberos basierenden System, wobei das System Folgendes umfasst: einen Server; einen Client, der konfiguriert ist, um an den Server verkoppelt zu werden; ein Schlüsselverteilungszentrum, das konfiguriert ist, um für den Client und den Server als eine vertrauenswürdige dritte Partei zu wirken; gekennzeichnet durch: einen Computercode, der betriebsfähig ist, um eine Triggernachricht an dem Server zu erzeugen; einen Computercode, der an den Server verkoppelt ist, der betriebsfähig ist, um eine Nonce an dem Server zu erzeugen; einen Computercode, der an den Server verkoppelt ist, der betriebsfähig ist, um die Triggernachricht und die Nonce an den Client zu übermitteln; einen Computercode, der an den Client verkoppelt ist, der betriebsfähig ist, um die Triggernachricht und die Nonce an dem Client zu empfangen; einen Computercode, der an den Client verkoppelt ist, der betriebsfähig ist, um eine Nonce als eine returned_nonce an dem Client zu bezeichnen; einen Computercode, der an den Client verkoppelt ist, der betriebsfähig ist, um eine second_nonce an dem Client zu erzeugen; einen Computercode, der an den Client verkoppelt ist, der betriebsfähig ist, um eine Antwortnachricht auf die Triggernachricht zu erzeugen; einen Computercode, der an den Client verkoppelt ist, der betriebsfähig ist, um die Antwortnachricht, die returned_nonce und die second_nonce an den Server zu übermitteln; einen Computercode, der an den Server verkoppelt ist, der betriebsfähig ist, um den Wert der returned_nonce mit dem Wert der Nonce, die durch den Server erzeugt wurde, zu vergleichen.