KEY MANAGEMENT BETWEEN A CABLE TELEPHONY ADAPTER AND ASSOCIATED SIGNALING CONTROLLER

Abstract: A highly scalable key management architecture for secure client-server systems used in IP telephony network, wherein cryptographic state needs to be saved only by the clients. This architecture takes advantage of existing key management protocols, Kerberos with the PKINIT (public key) extension, to provide an IP telephony system having a high degree of scalability. In the case of lost security associations, the architecture provides for lightweight rekeying operations that allow clients to quickly re-establish the lost association or switch to a different server. The key management architecture includes a method for establishing a secure channel between an IP telephony endpoint and Server in an IP telephony network. The endpoint is coupled to a user and the Server is coupled to the IP telephony network. The method comprises steps of transmitting from the endpoint to a key distribution center a request for a security ticket, receiving the security ticket from the key distribution center, transmitting from the endpoint to the Server a request for a sub-key, receiving the sub-key from the Server, and establishing a secure channel between the endpoint and the Server using the sub-key.

Description: KEY MANAGEMENT BETWEEN A CABLE TELEPHONY ADAPTER AND ASSOCIATED SIGNALING CONTROLLER CROSS-REFERENCES TO RELATED APPLICATIONS This application claims priority from co-pending U.S. Provisional Patent Application Serial No. 60/128,772 filed April 9, 1999, the disclosure of which is incorporated herein in its entirety for all purposes. FIELD OF THE INVENTION This invention relates generally to key management for Client-Server systems, and more particularly, to a scalable key management system for use in IP telephony networks. BACKGROUND OF THE INVENTION In an Internet Protocol (IP) telephony network, a network server may be responsible for setting up phone calls with up to 100,000 clients. The clients may be coupled to the telephony network via cable telephony adapter (CTA) devices. In order to secure call signaling, an Internet Protocol Security (IPSec) association is set up between each client and the server. This has to be done in a timely fashion to minimize the CPU overhead at the server and to minimize the call setup delay. In order to handle large numbers of clients, key management needs to be as fast as possible. For example, security associations might be lost when a server goes down or become too busy to handle all of its clients. The lost security associations must then be re-establish again when needed. Manual administration of clients is unsuitable because of the high overhead costs and lack of scalability . Other techniques used in architectures unrelated to IP telephony are also not suitable, since they do not provide the desired scalability and low administration overhead. SUMMARY OF THE INVENTION The present invention includes a highly scalable key management architecture for secure client-server systems used in IP telephony network, wherein cryptographic state needs to be saved only by the clients. This architecture takes advantage of existing key management protocols, Kerberos with the PKINIT (public key) extension, to provide an IP telephony system having a high degree of scalability. In the case of lost security associations, the architecture provides for lightweight rekeying operations that allow clients to quickly re-establish the lost association or switch to a different server. In one embodiment of the present invention, a method for establishing a secure channel between an IP telephony endpoint and Server in an IP telephony network is provided. The endpoint is coupled to a user and the Server is coupled to the IP telephony network. The method comprises steps of transmitting from the endpoint to a key distribution center a request for a security ticket, receiving the security ticket from the key distribution center, transmitting from the endpoint to the Server a request for a sub- key, receiving the sub-key from the Server, and establishing a secure channel between the endpoint and the Server using the sub-key. A further understanding of the nature and the advantages of the inventions disclosed herein may be realized by reference to the remaining portions of the specification and the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 shows a telephony network constructed in accordance with the present invention; FIG. 2 shows message exchange diagram for establishing a secure communication channel in accordance with the present invention; and FIG. 3 shows a method for establishing a secure communication channel using the messages of FIG. 3. DESCRIPTION OF THE SPECIFIC EMBODIMENTS Embodiments of the present invention provide for establishing a secure channel between an IP telephony endpoint and a Server in an IP telephony network. In the embodiments discussed herein, a cable telephony adapter (CTA) device is representative of the IP telephony endpoint and a Signaling Controller (SC) is representative of the Server. However, the present invention is suitable for use with other types of network endpoints and Servers not discussed herein. FIG. 1 shows a portion of a telephony network 100 constructed in accordance with the present invention. To access the telephony network, CTA 102 provides access to a user 104 via a Hybrid Fiber/Coax (HFC) head-end 106. The HFC head-end 106 has the capacity to provide access to other users as shown at 108. The HFC head-end is also coupled to a Signaling Controller (SC) 110 which is coupled to a telephony network backbone 114. The Signaling Controller is used to control the CTA's access to the telephony network. A key distribution center (KDC) 112, is also coupled to the telephony network backbone 114. The KDC 112 issues Kerberos tickets, which are in turn used to generate sub-keys for secure connection protocols, such as the IPSec encapsulating security payload (ESP) protocol, or other secure connections. The network 100 also includes a customer service representative (CSR) center 116, a provisioning certification authority (C A) 118 and a billing host 120. Thus, in the network 100 it is possible for the user 104 to access the telephony backbone 114 via the CTA 102 using a secure protocol. Embodiments of the present invention include the use of the Kerberos protocol with the public key PKINIT extension for key management. This protocol is based on Kerberos tickets, which are cookies, encrypted with the particular server's key. The Kerberos ticket is used to both authenticate a client to a server and to establish a session key, which is contained in the ticket. Accessing Kerberos services can be done using the Generic Security Service Application Program Interface (GSS-API) standard. In one embodiment of the present invention, two-way authentication with public key certificates is used by the CTA to obtain a Signaling Controller ticket from the KDC. A corresponding session key is delivered to the CTA sealed with either the CTA's public key or with a secret derived from a Diffie-Hellman exchange. The Signaling Controller ticket is kept for a relatively long period of time, for example, days or weeks. The length of this period can be adjusted based on network performance requirements. In addition, the Signaling Controller ticket is used to establish a symmetric session key, which is in turn used to establish a set of keys for use with the IPSec ESP mode. The keys used by IPSec are not derived from the session key itself. Instead, another random key (i.e., a sub-key) is generated for each phone call and then used to derive the IPSec keys. Thus, the Signaling Controller does not have to keep state. After it derives all the required keys from the sub-key and exchanges signaling messages with the CTA, the Signaling Controller can throw away the ticket along with all of the associated keys. The use of the Kerberos protocol with the PKINIT extension in embodiments of the present invention provides several advantages. For example, the Signaling Controller is not required to keep state - Kerberos tickets need to be kept only by the endpoints (CTAs). Also, IPSec Security Associations can be torn down when no longer needed and quickly re-established with efficient key management based on the Kerberos tickets. The protocol runs over both TCP and UDP protocols, and is a widely available standard, with multiple vendors providing support for both Kerberos and PKINIT. In one embodiment, within the PKINIT protocol, RS A is used for both key delivery and authentication. In another embodiment, a PKINIT option may be used wherein Diffie-Hellman is used for the key exchange and RS A is used for authentication. In general, embodiments of the present invention are suitable for use with any public key algorithms within PKINIT for both authentication and key exchanges. FIG. 2 shows a message exchange diagram 200 illustrating how the CTA uses Kerberos to obtain the sub-key, which in turn, is used to derive IPSec ESP keys for the CTA-to-Signaling Controller signaling messages. In the exchange diagram 200, only some of the information carried in the messages is provided in order to present a clear description of the protocol. The exchange diagram 200 shows messages transmitted or received at the CTA 102 at line 220, the KDC 112 at line 222, and the Signaling Controller 110 at line 224. FIG. 3 shows a flow diagram 300 illustrating how the messages of FIG. 2 are exchanged in accordance with the present invention. At block 302, a PKINIT Request is sent from the CTA 102 to the KDC 112 as shown by message 202. This request includes the CTA signature and certificate - used by the KDC to authenticate the CTA. This request also carries the current time - used by the KDC to verify that this message is not a replay or a retransmission of an old message. The PKINIT Request also contains a random value (called a nonce) that will be used to bind a subsequent PKINIT Reply message to this request. In the case that a Diffie-Hellman exchange is used, the CTA will also include its Diffie-Hellman parameters and public value in the PKINIT Request. At block 304, the KDC 112 receives and verifies the PKINIT Request and then issues to the CTA a ticket for the Signaling Controller encrypted with the Signaling Controller's service key. Inside this encrypted ticket are a symmetric session key, its validity period and the CTA identity. Also in this step, this ticket will be sent back to the CTA 102 inside a PKINIT Reply, shown by message 204. The PKINIT Reply message also contains KDC's certificate and signature for authenticating the KDC, along with the nonce from the PKINIT Request to protect against replays. If a Diffie-Hellman exchange is used, the KDC also places its Diffie-Hellman public value into this message. The PKINIT Reply also contains a second copy of the session key and its validity period found in the ticket - intended to be decrypted and used by the CTA. This second copy of the session key and its associated attributes are either encrypted with a Diffie-Hellman-derived secret or enveloped with the CTA's public key. Here, enveloped means that the session key along with its associated attributes are not encrypted directly with the CTA's public key. Within the PKINIT Reply the public key is used to encrypt a random symmetric key that is in turn used to encrypt another symmetric key which is then finally used to encrypt the session key and its attributes. This embodiment uses the PKINIT standard as is, even though in this case, simplifications to the PKINIT Reply seem possible. If a Diffie-Hellman exchange is not used, then the Reply contains message items as shown at 226. At block 306, an application (AP) Request is sent from the CTA 102 to the Signaling Controller 110 as shown by message 206. Here, a CTA has already obtained a Signaling Controller ticket and now initiates key management with the Signaling Controller by sending it an AP Request message. The AP Request contains the Signaling Controller ticket along with the CTA name, timestamp and a message hash - all encrypted with the SC session key. The timestamp is used to check for replays of old AP Request messages. At block 308, the Signaling Controller 110 receives an AP Request. It first decrypts and validates the ticket with its service key. It then takes the session key out of the ticket and uses it to decrypt and validate the rest of the AP Request. Then, the Signaling Controller generates a random sub-key and encrypts it along with the current timestamp with the session key. It places this information into an AP Reply message 208 and sends it back to the CTA. At block 310, the CTA receives and validates the AP Reply, after which it shares the sub-key with the Signaling Controller. Both sides independently derive (with some one-way function) a set of IPSec encryption and authentication keys from this sub- key. After that, all signaling messages between the CTA and the Signaling Controller will be protected with an IPSec channel. This establishment of the IPSec channel is symbolically illustrated in FIG. 2 at 210 - even though this step does not involve an exchange of messages. In the embodiment of the invention depicted in FIGS. 2 and 3, the PKINIT exchange is performed at long intervals in order to obtain an intermediate symmetric session key. This session key is shared between the CTA and the Signaling Controller (via the Signaling Controller Ticket). In this embodiment, the PKINIT Request/Reply messages, shown at 202 and 204, are sent over a TCP/IP connection. This is because a single PKINIT Request or Reply message, containing public key and Diffie-Hellman information may be too large to fit into a single UDP packet. The use of TCP instead of UDP may have some impact on performance, but since the PKINIT exchange occurs at infrequent intervals (days or weeks apart) and is not tied to the phone calls, the impact on performance is not significant. The session key is used in the AP Request and AP Reply messages, shown at 206, 208 and are exchanged for each phone call, to establish a symmetric sub-key. This sub-key is used to derive all of the IPSec ESP keys and starting sequence numbers, used for both directions. The AP Request and AP Reply messages are small enough to fit into a single UDP packet, and thus will run over UDP. The present invention provides a highly scalable key management architecture for secure client-server systems used in IP telephony networks. It will be apparent to those with skill in the art that modifications to the above methods and embodiments can occur without deviating from the scope of the present invention. Accordingly, the disclosures and descriptions herein are intended to be illustrative, but not limiting, of the scope of the invention which is set forth in the following claims.

Claims: WHAT IS CLAIMED IS: L A method for establishing a secure channel between an IP telephony endpoint and Server in an IP telephony network, wherein the endpoint is coupled to a user and the Server is coupled to the IP telephony network, the method comprising steps of: transmitting from the endpoint to a key distribution center a request for a security ticket; receiving the security ticket from the key distribution center; transmitting from the endpoint to the Server a request for a sub-key; receiving the sub-key from the Server; and establishing a secure channel between the endpoint and the Server using the sub-key. 2. The method of claim 1 , wherein the endpoint is a cable telephony adapter. 3. The method of claim 1 , wherein the server is a Signaling Controller. 4. The method of claim 1 , wherein the secure channel is an IPSec channel.

Inventors: MEDVINSKY SASHA, MEDVINSKY, SASHA
Applicants: GEN INSTRUMENT CORP, MEDVINSKY SASHA, GENERAL INSTRUMENT CORPORATION, MEDVINSKY, SASHA
Application year: 2000
Main classification: H04L29
IPC codes: G06F1, G06F12, G06F21, H04L9, H04L29