WO2000062519A2 - Built-in manufacturer's certificates for a cable telephony adapter to provide device and service certification - Google Patents

Built-in manufacturer's certificates for a cable telephony adapter to provide device and service certification Download PDF

Info

Publication number
WO2000062519A2
WO2000062519A2 PCT/US2000/009318 US0009318W WO0062519A2 WO 2000062519 A2 WO2000062519 A2 WO 2000062519A2 US 0009318 W US0009318 W US 0009318W WO 0062519 A2 WO0062519 A2 WO 0062519A2
Authority
WO
WIPO (PCT)
Prior art keywords
cta
telephony
certificate
network
provisioning
Prior art date
Application number
PCT/US2000/009318
Other languages
French (fr)
Other versions
WO2000062519A3 (en
WO2000062519A9 (en
Inventor
Sasha Medvinsky
Original Assignee
General Instrument Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by General Instrument Corporation filed Critical General Instrument Corporation
Priority to US10/296,846 priority Critical patent/US7376837B1/en
Priority to AU40792/00A priority patent/AU4079200A/en
Priority to CA002370471A priority patent/CA2370471A1/en
Priority to EP00920214A priority patent/EP1171989A2/en
Priority to US09/668,426 priority patent/US6892308B1/en
Publication of WO2000062519A2 publication Critical patent/WO2000062519A2/en
Publication of WO2000062519A3 publication Critical patent/WO2000062519A3/en
Publication of WO2000062519A9 publication Critical patent/WO2000062519A9/en
Priority to US11/028,821 priority patent/US20050120248A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1408—Protection against unauthorised use of memory or access to memory by using cryptography
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2207/00—Indexing scheme relating to methods or arrangements for processing data by operating upon the order or content of the data handled
    • G06F2207/72—Indexing scheme relating to groups G06F7/72 - G06F7/729
    • G06F2207/7219—Countermeasures against side channel or fault attacks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2211/00—Indexing scheme relating to details of data-processing equipment not covered by groups G06F3/00 - G06F13/00
    • G06F2211/007—Encryption, En-/decode, En-/decipher, En-/decypher, Scramble, (De-)compress
    • G06F2211/008—Public Key, Asymmetric Key, Asymmetric Encryption
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2129—Authenticate client device independently of the user

Definitions

  • This invention relates generally to the field of network telephony, and more particularly, to a system for registering a telephony device with a telephony network.
  • a cable telephony adapter (CTA) device is used to allow a user to send and receive information in secure transactions over an IP telephony network.
  • CTA cable telephony adapter
  • a series of signaling messages are exchanged that register the CTA device with the IP telephony network before a secure channel with another user can be established.
  • the authentication provides protocol security and allows the IP telephony network to authenticate the identity of the CTA device.
  • the CTA should be authenticated from the very beginning of the provisioning process. Otherwise the provisioning process would be open to additional denial of service attacks - since some provisioning exchanges can be forged.
  • the present invention includes a system for using a manufacturer issued certificate to authenticate a CTA device during registration with an IP telephony network.
  • the issuance of another certificate allows the CTA to authenticate itself with a specific IP telephony network.
  • the IP telephony network does not need to keep track of CTA hardware identifiers when outside of the provisioning system.
  • a method of operating a cable telephony adapter in an IP telephony network includes steps of storing a manufacturer issued certificate in the cable telephony adapter, providing the manufacturer issued certificate to the telephony network, receiving a network issued certificate, and registering for telephony services with the telephony network using the network issued certificate.
  • a cable telephony adapter for interfacing a user to a telephony network.
  • the cable telephony adapter includes a telephony network interface having logic to couple to the telephony network and a user interface having logic to couple to a user device.
  • the cable telephony adapter also includes a cryptographic module having logic to store a manufacturer issued certificate and a processor coupled to the telephony network interface and the cryptographic module, and having logic to use the manufacturer issued certificate to obtain a network issued certificate.
  • FIG. 1 shows a portion of a telephony network including a CTA containing a manufacturer issued certificate in accordance with the present invention.
  • FIG. 2 shows an exemplary embodiment of a CTA constructed in accordance with the present invention
  • FIG. 3A shows an HFC access state machine diagram for a CTA constructed in accordance with the present invention
  • FIG. 3B shows a telephony access state machine diagram for a CTA constructed in accordance with the present invention
  • FIG. 4 shows a messaging diagram for provisioning a CTA in accordance with the present invention
  • FIG. 5 shows a method for provisioning a CTA using the messages of FIG. 4;
  • FIG. 6 shows a messaging diagram for de-provisioning a CTA in accordance with the present invention
  • FIG. 7 shows a messaging diagram for implementing change of service for a CTA in accordance with the present invention
  • FIG. 8 shows a messaging diagram for moving a CTA to a different HFC segment in accordance with the present invention
  • FIG. 9 shows a method for moving a CTA to a different HFC segment using the messages of FIG. 8;
  • FIG. 10 shows a messaging diagram for activating a CTA after repair in accordance with the present invention.
  • FIG. 1 shows a portion of a telephony network 100 including a CTA 102 containing one or more manufacturer issued certificates in accordance with the present invention.
  • the 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, used to control the CTA's access to the telephony network.
  • SC Signaling Controller
  • a key distribution center (KDC) 112 issues Kerberos tickets, which are in turn used to generate sub-keys for secure connection protocols, such as the Internet protocol security (IPSec) encapsulating security payload (ESP) protocol, or other secure connections.
  • IPSec Internet protocol security
  • ESP security payload
  • the network 100 also includes a customer service representative (CSR) center 116, a provisioning certification authority (CA) 118 and a billing host 120.
  • CSR customer service representative
  • CA provisioning certification authority
  • FIG. 2 shows an exemplary embodiment of the CTA 102 constructed in accordance with the present invention.
  • the CTA 102 includes a cable interface (I/F) 202 which can be coupled to the telephony network at 204, and a user I/F 206 which can be coupled to a user at 208.
  • the CTA 102 also includes a processor 210, a memory 212 and a cryptographic module 214.
  • the processor 210 is coupled to the cable I/F 202, as shown at 216, to provide decryption and encryption of information received and transmitted on the telephony network.
  • the connection to the telephony network at line 204 carries secure encrypted information
  • a connection between the cable I/F and the user I/F, as shown at line 218, carries unencrypted information.
  • the unencrypted information is commonly referred to as clear information and extends back to the user on line 208.
  • the cryptographic module 214 is coupled to the processor module 210 and includes a public/private key pair that may be used to provide secured encrypted communication between the CTA 102 and the telephony network.
  • the cryptographic module also includes a permanent device ID that is provided by the manufacturer that can be used to identify the device. This permanent device ID and the public key are embedded inside the manufacturer issued CTA certificate.
  • the processor 210 can access the memory 212 to store CTA operating parameters, received telephony network parameters, or other cryptographic information used during operation of the CTA.
  • FIGS. 3 A and 3B show two separate provisioning state machines that are performed by the CTA 102.
  • FIG. 3 A shows an access state machine diagram 300 for HFC access provisioning.
  • FIG. 3B shows a telephony state machine diagram 302 for telephony access provisioning. Operation of the state machines are described in the following sections.
  • the states in the HFC access state machine 300 are: (304) HFC Not Configured - In this state the CTA is not provisioned and has not yet tried to register with the HFC head-end. (306) Unprovisioned HFC Access - In this state the CTA is registered with the HFC head-end, but there is no customer account set up. One reason the CTA was allowed to register, is so that it can get access to the CSR to get provisioned in both the telephony and HFC networks. (308) Fully Registered with HFC - In this state the CTA is registered in the HFC network's authorization database. However, the CTA's internal state does not yet permit it to send packets anywhere within the telephony network. In order to get to this state, the CTA customer account was set up in the telephony network. The Provisioning CA in the telephony network has notified the HFC head-end that
  • CTA access to the telephony network should be fully enabled.
  • the CTA is integrated with general purpose Cable Modem access.
  • the Cable Modem has been registered for HFC access to some non-telephony network services (e.g. Internet access).
  • HFC was rebooted and is now given full access to the telephony network or some other network services.
  • the states in the telephony access state machine 302 are: (312) Telephony I/F Not Configured - In this state the CTA is not provisioned with the telephony network and has not yet tried to register with the telephony network.
  • PKLNIT exchange with the Network Operator-issued certificate will fail. That will cause the CTA to go back to the Telephony I/F Not Configured state, where the CTA may get provisioned again.
  • Provisioned Access with Ticket - To get to this state the CTA performed a PKLNIT exchange with the new certificate and was granted the ability to make telephone calls, based on the subscribed service options.
  • Provisioned Telephony Signaling Security - To get to this state the CTA performed a Kerberos AP Req/Rep exchange with the signaling controller and set up IPSec Security Associations to protect all signaling messages between them.
  • items 1, 3 and 5 are stored in the cryptographic module 214 and items 2, 4 are stored in the cryptographic module 214 or the memory 212.
  • An RSA key pair that is installed at the factory 2.
  • An X.509 certificate issued by a network operator during the provisioning phase for the CTA RSA key pair. This certificate is good only for a particular network operator.
  • a manufacturer's certificate signed by a root CA This certificate is normally installed at the factory, but may be embedded in software downloaded while online. This certificate should be valid for at least the expected lifetime of the CTA.
  • a root public key used by the CTA to verify network operator's certificate that it obtains during provisioning.
  • provisioning scenarios are herein described for provisioning a CTA in accordance with the present invention. These specific provisioning scenarios are assuming that the KDC and the Signaling Controller are co-located on the same host. However, in general this invention is not limited to specific physical locations of the KDC and the Signaling Controller and their co-location on the same host is not required.
  • FIG. 4 shows a message exchange diagram 400 illustrating how messages are exchanged between the components of the telephony network 100, to achieve initial customer registration in accordance with the present invention.
  • the exchange diagram 400 shows messages transmitted or received at the CTA/T A/customer 104/102 at line 404, the HFC head-end 106 at line 406, the KDC 112 and Signaling Controller 116 at line 408, the CSR center 116 at line 410, the provisioning CA 118 at line 412 and the billing host 120 at line 414.
  • FIG. 5 shows a flow diagram 500 illustrating the process of initial customer registration utilizing a CTA with a manufacturer issued certificate and messages shown in FIG. 4 in accordance with the present invention.
  • the CTA coupled to the HFC includes a manufacturer issued certificate in accordance with the present invention.
  • messages are exchanged between the CTA and the HFC head-end to initialize unprovisioned HFC access. These messages are shown in FIG. 4 at 416.
  • the CTA receives a code image from the HFC head-end that includes the Network Operator Certificate. This certificate will later be used by the CTA to validate both the KDC's certificate and the CTA's own certificate issued by the network operator.
  • the standard DOCSIS registration process for a cable modem is utilized in the case of an integrated CTA or for attached Customer Premises Equipment (CPE) in the case of a telephony adapter (TA). Since the CTA (or TA) is not provisioned at this point, it is assigned an unprovisioned IP address. This restricts the CTA to exchanging messages with the following hosts (IP addresses):
  • a Kerberos Ticket is obtained with PKLNIT as shown in FIG. 4 at 418.
  • PKLNIT This is a standard PKLNIT exchange, for example, as described in section 5.2.2 of the '772 provisional patent application.
  • the certificate used by the CTA during the PKLNIT is one that was installed in the factory and signed by the manufacturer. This certificate contains the CTA MAC address, which may be verified by the KDC. In one embodiment, it is recommended that the KDC checks with the HFC head-end to see if the IP address is valid and if the MAC address (in the certificate) corresponds to that IP address and has not been marked as "bad" at the HFC head-end.
  • the HFC head-end employs some sort of a physical layer cloning detection scheme that may identified the current CTA unit as a clone.
  • the CTA manufacturer certificate sent in the PKLNIT request is also required in order for the Signaling Controller to verify the signature on the CTA certificate.
  • the CTA also verifies the KDC signature and certificate during this step - the KDC certificate is verified with the previously obtained Network Operator Certificate.
  • the obtained Kerberos ticket has additional information, which restricts the CTA to telephone calls to only a single destination - the CSR. If desired, the unprovisioned CTA may also be allowed to call the 911 number. This restriction may be placed inside an authorization-data field inside the Kerberos ticket.
  • the manufacturer issued CTA certificate obtained by the Signaling Controller during the PKLNIT exchange is passed on (along with the CTA's unprovisioned IP address) to the provisioning CA as shown in FIG. 4 at 420.
  • the CA will save this certificate and will later (when it receives customer information) use it to generate another CTA certificate, specific to this telephone network.
  • the IP address of the Signaling Controller (same as the IP Address of the KDC) will also be saved by the provisioning CA, so that later in the process it can inform the Signaling Controller about the telephone number of the newly provisioned CTA.
  • an IPSec ESP Session is established, as shown at 424. This is the first action that happens when the unprovisioned CTA or TA goes off-hook, as shown at 426.
  • the Kerberos ticket is used in AP Request (Req) and AP Reply (Rep) messages to mutually authenticate the CTA and Signaling Controller and to obtain a sub- key. This sub-key is used to derive all of the necessary keying material for IPSec ESP.
  • the Kerberos ticket may contain restrictions, limiting the CTA to calls to the CSR (and possibly the 911 number).
  • the Signaling Controller must enforce these restrictions on the subsequent calls from this CTA.
  • a call to the CSR is setup as shown in FIG. 4 at 428.
  • signaling messages are exchanged in order to establish a voice connection with the CSR.
  • This includes CTA-to-SC messages, CTA-to-CTA messages, and possibly signaling messages exchanged with another Network Server.
  • a sub-key distribution scheme for securing CTA-to-Network Server and CTA-to-CTA links (i.e one scheme is explained in the '772 application at section 5.2.3.1) is also included in this step. All signaling messages are sent over a secure IPSec ESP layer.
  • the CTA software may be configured so that when it is in the unprovisioned state, it automatically dials the CSR as soon as the phone goes off-hook. In this case, however, the unprovisioned CTA would not be able to dial 911. If 911 access is a requirement, then the CSR telephone number should be dialed manually.
  • the customer information entered by the CSR goes into the provisioning CA first, as shown at 432, which assigns the customer a telephone number, appropriate for where the customer is located.
  • the CSR has a way to determine the calling CTA's (unprovisioned) IP address, which is also sent to the provisioning CA, along with the customer information. This information will enable the provisioning CA to send messages (described later in this scenario) to configure the calling CTA. Also, the CTA IP address is used by the provisioning CA to find the manufacturer issued certificate (received as describe above) for the calling CTA. This means that the CSR's CTA has an ability to display the IP address of the calling CTA. Alternatively, if the CSR is using a regular phone, connected to a PSTN Gateway, the CSR gets the IP address from the gateway.
  • the provisioning CA updates the billing host with the customer information and the assigned telephone number, as shown in FIG. 4 at 434.
  • the new telephone number and the corresponding MAC address (found in the original manufacturer issued CTA certificate) are sent over from the provisioning CA to the Signaling Controller, as shown at FIG. 4 at 436. This will allow the Signaling Controller to accept a CTA certificate that contains that telephone number.
  • the MAC address is used by the Signaling Controller (in the following message) to provision the necessary HFC resources for the CTA.
  • the Signaling Controller provisions the CTA for the required HFC resources, as shown in FIG. 4 at 438.
  • the Signaling Controller sends to the HFC head-end the CTA MAC address and routing information - legal source and destination IP addresses for this CTA. Other information may also be required by the HFC head-end.
  • the CTA is allowed to exchange messages with any node in the IP telephony network.
  • the provisioning is completed after the CTA receives its new certificate, signed by the new Network Operator, and containing CTA identifying information for this telephone network (the phone ID), as shown in FIG. 4 at 440.
  • the phone ID may be a one-way function of the phone number (e.g. SHA-1 hash), but cannot be the phone number itself (which may be unlisted).
  • the Network Operator certificate needed to verify the new CTA certificate should already be present in the CTA.
  • the CTAjs ready to place and receive telephone calls anywhere within this telephone network.
  • the message shown at 440 is acknowledged at 442.
  • the CSR gets back the telephone number from the provisioning CA (e.g. on the screen), as shown in FIG. 4 at 444, and relays it over the phone to the CTA customer, along with how the customer will be billed, etc., as shown in FIG. 4 at 446.
  • the CTA is fully provisioned to use the telephony network.
  • FIG. 6 shows a message exchange diagram 600 illustrating how messages are exchanged between the components of the telephony network 100 to achieve de- provisioning in accordance with the present invention.
  • the exchange diagram 600 shows messages transmitted or received from the CTA/T A/customer 104/102 at line 604, the
  • HFC head-end 106 at line 606, the KDC 112 and Signaling Controller 116 at line 608, the CSR center 124 at line 610, the provisioning CA 126 at line 612 and the billing host 128 at line 614.
  • the customer may wish to discontinue currently established telephone service for the CTA. It may be that the customer is changing IP telephony providers, or moving to a new location not supported by the current IP telephony provider.
  • the customer has a valid Kerberos ticket and has established an IPSec ESP session, as shown at 616. It will also be assumed that a call to the CSR has been performed as shown at 618.
  • the customer simply requests termination of the service on a particular date with the CSR, as shown at 620.
  • the CSR relays this information to the provisioning CA, as shown at 622.
  • the provisioning CA in turn sends a termination request to the billing host, as shown at 624 and the Signaling Controller, as shown at 626.
  • the Signaling Controller in turn propagates the termination request to the HFC head-end, as shown at 628.
  • the CTA Next time that the CTA tries to use its Kerberos ticket before making a phone call, the ticket will be rejected (because that phone number is no longer in the Signaling Controller's database). That will cause the CTA to try and obtain another Kerberos ticket. It will try to perform a PKLNIT exchange with its Network Operator signed certificate but will fail again. This will cause the CTA to remove the invalid certificate and transition into an unprovisioned state.
  • the following scenario applies in cases where a new IP telephony customer is registering with a particular network operator, and the CTA he or she is using is not brand-new out of the factory.
  • the CTA may have been used:
  • the CTA will attempt to perform a PKLNIT exchange, using an old certificate that is no longer valid.
  • the CTA will get an error back from the
  • FIG. 7 shows a message exchange diagram 700 illustrating how messages are exchanged between the components of the telephony network 100 to achieve change of service in accordance with the present invention.
  • the exchange diagram 700 shows messages transmitted or received from the CTA/T A/customer 104 at line 704, the HFC head-end 106 at line 706, the KDC 112 and Signaling Controller 116 at line 708, the CSR center 124 at line 710, the provisioning CA 126 at line 712 and the billing host 128 at line 714.
  • the CTA is re-provisioned to change established service options. For example, a Caller ID service may be added or a different billing option selected, etc.
  • the change of service will not require the provisioning CA to issue a new CTA certificate.
  • the one exception is where a CTA is provisioned for an additional phone number (on another CTA port). In that case, the provisioning CA will issue a new CTA certificate containing an updated list of phone IDs for that CTA.
  • the customer calls up the CSR to request the changes in service, as shown at 716.
  • the CSR sends the update to the provisioning CA, as shown at 718, which relays that change to the Billing Host, as shown at 720 and the Signaling Controller, as shown at 722.
  • the Signaling Controller in turn relays the change to the HFC head-end, as shown at 724.
  • the CTA will be issued a new certificate, as shown at 726, and may also be instructed by the HFC head-end to download a different version of the CTA software.
  • the CTA already possesses a network operator certificate, so that it is able to perform a signature verification check along with the time validity check on the new certificate. The time validity check will not only make sure that the issued certificate had not expired - it will also make sure that the new certificate's starting time is greater than the starting time of the old certificate (i.e. the new certificate is not a replay).
  • FIG. 8 shows a message exchange diagram 800 illustrating how messages are exchanged between the components of the telephony network 100 to move a CTA to a different HFC segment in accordance with the present invention.
  • the exchange diagram 800 shows messages transmitted or received from the CTA/T A/customer 104 at line 804, the HFC head-end 106 at line 806, the KDC 112 and Signaling Controller 116 at line 808, the CSR center 124 at line 810, the provisioning CA 126 at line 812 and the billing host 128 at line 814.
  • the exchange diagram 800 also shows messages transmitted or received from a new HFC head-end at 816, and a new Signaling Controller at 818.
  • the new HFC head-end and new Signaling Controller are not shown in FIG. 1.
  • FIG. 9 shows a flow diagram 900 illustrating the process of moving a CTA to a different HFC segment utilizing messages shown in FIG. 8 in accordance with the present invention.
  • the CTA owner moves to a new location, corresponding to a new HFC segment.
  • the same IP telephony company serves the new area, but the CTA has to be assigned a new telephone number and re-provisioned for the new HFC segment.
  • the customer moves to a different location, still covered by the same IP Telephony company, however, the customer now has to connect to a different HFC head-end that has not been previously provisioned for this CTA.
  • the CTA is initialized with an un-provisioned IP address by the new HFC head-end as shown in FIG. 8 at 820.
  • the CTA proceeds with a PKLNIT exchange with the new Signaling Controller, using its current certificate issued by the Network Operator, as shown in FIG. 8 at 822.
  • the new Signaling Controller does not recognize the certificate and the PKLNIT exchange fails.
  • the CTA now falls back to a PKLNIT exchange with the new Signaling Controller using the manufacturer issued certificate and succeeds, as shown in FIG. 8 at 824.
  • the manufacturer issued CTA certificate obtained by the KDC during the PKLNIT exchange is passed on to the provisioning CA, as shown in FIG. 8 at 826.
  • the provisioning CA doesn't actually need this certificate, because it already contains a CTA certificate (for the old HFC segment). This step is done for consistency - the KDC does this every time for an unprovisioned CTA.
  • the KDC also sends the unprovisioned IP address for that CTA.
  • the IP address of the Signaling Controller (which may be the same as the IP address of the KDC) will also be saved by the Provisioning CA, so that it can later inform the Signaling Controller about the new Customer ID of the newly provisioned CTA.
  • an IPSec ESP Session is established, as shown in FIG. 8 at 828. This is the first action that happens when the unprovisioned CTA or TA goes off- hook.
  • a Kerberos ticket is used in the AP Request / AP Reply messages to mutually authenticate the CTA and Signaling Controller and to obtain a sub-key. This sub-key is used to derive all of the necessary keying material for IPSec ESP.
  • the Kerberos ticket contains restrictions, limiting the CTA to calls to the CSR (and possibly the 911 number).
  • the new Signaling Controller must enforce these restrictions on the subsequent calls from this CTA.
  • a call to CSR is setup, as shown in FIG. 8 at 830.
  • signaling messages are exchanged, in order to establish a voice connection with a CSR.
  • This includes CTA-to-SC messages, CTA-to-CTA messages, and possibly signaling messages exchanged with another Network Server.
  • the key distribution for securing CTA-to-Network Server and CTA-to-CTA links is also included in this step. All signaling messages are sent over a secure IPSec ESP layer.
  • the CTA software may be configured, so that when it is in an unprovisioned state, it automatically dials the CSR, as soon as the phone goes off-hook. In this case, however, an unprovisioned CTA will not be able to dial 911. If that is a requirement, then the CSR telephone number should be dialed manually.
  • the customer information is updated, as shown in FIG. 8 at 832.
  • the CSR will send (manually enter) the provisioning CA the old telephone number and the new customer information, as shown in FIG. 8 at 834.
  • the provisioning CA will update the billing host with the new customer information and with both the old and the new customer ID, based on the new customer location, as shown in FIG. 8 at 836.
  • the CSR must have a way to determine the calling CTA's (unprovisioned) IP address, which is also sent to the provisioning CA, along with the customer information. This information will enable the provisioning CA to send messages (described later in this scenario) to configure the calling CTA.
  • the CTA IP address is also used by the provisioning CA to find the manufacturer issued certificate for the calling CTA.
  • the CSR's CTA must have an ability to display the IP address of the calling CTA.
  • the CSR gets the IP address from the gateway.
  • the Old Signaling Controller is notified that the old customer
  • Controller that the CTA MAC address is no longer provisioned for that particular HFC segment as shown in FIG. 8 at 840.
  • the new phone number and the corresponding MAC are sent over from the provisioning CA to the new Signaling Controller, as shown in FIG. 8 at 842.
  • This will allow the new Signaling Controller to accept a CTA certificate that contains the corresponding phone ID.
  • the MAC address is used by the new Signaling Controller (in the following message) to provision the necessary HFC resources for the CTA.
  • the new Signaling Controller provisions the CTA for the required HFC resources. It sends to the new HFC head-end the CTA MAC address and routing information - legal source and destination IP addresses for this CTA, as shown in FIG. 8 at 844. Other information may also be required by the new HFC head-end.
  • the CTA is allowed to exchange messages with any node in the IP telephony network.
  • the provisioning is completed in this step after the CTA receives its new certificate signed by the new Network Operator and containing the new phone ID, as shown in FIG. 8 at 846. Now, the CTA is ready to place and receive telephone calls anywhere within this telephone network.
  • the CSR gets the new telephone number from the provisioning CA, as shown in FIG. 8 at 848, and relays it over the phone to the CTA customer, as shown in FIG. 8 at 850. Repairing a CTA
  • certificates provided by the present invention can be used to repair and test the CTA, and thereafter, allow the customer to provision the repaired CTA for use in a telephony network.
  • the following steps for repair are:
  • a damaged CTA is shipped to a repair facility.
  • the CTA After the CTA is fixed, it needs to be tested. To test the CTA, it is re-provisioned for a special account associated with the repair facility and undergoes testing. This insures that the customer does not get billed for the telephone services that are being tested by the repair facility.
  • a test engineer removes the customer certificate in the CTA, possibly through the front panel controls on the CTA.
  • the customer is still provisioned in the telephony network and the certificate can always be loaded back from the network, as described in a previous section.
  • the CTA enters the unprovisioned state (even though the customer is still provisioned) and will follow the provisioning steps outlined above for Initial customer registration using the repair facility certificate.
  • the CTA is now provisioned for the repair facility to allowed the required testing to take place.
  • the repair facility certificate should have a short validity period (a few days or even a few hours).
  • the replacement CTA is provisioned as if it were a new CTA - see figures 4 and 5.
  • the CTA certificate was replaced with the one for the repair facility.
  • the test certificate is either removed from the CTA using the front panel or the CTA underwent the full de-provisioning process illustrated in FIG. 6. In any event the repair facility certificate expires in a relatively short time.
  • FIG. 10 shows a message exchange diagram 1000 illustrating how messages are exchanged between the components of the telephony network 100 to provision a CTA that has been returned from a repair facility.
  • the exchange diagram 1000 shows messages transmitted or received from the CTA/T A/customer 104 at line 1004, the HFC head-end 106 at line 1006, the KDC 112 and Signaling Controller 116 at line 1008, the CSR center 124 at line 1010, the provisioning CA 126 at line 1012 and the billing host 128 at line 1014.
  • the CTA gets unprovisioned access to the HFC segment connected to the repair facility and attempts to initialize provisioned access, as shown at 1020.
  • the CTA performs an unprovisioned PKLNIT exchange with the local Signaling Controller, as shown at 1022, which relays the manufacturer issued CTA certificate to the provisioning CA, as shown at 1024.
  • the provisioning CA has no use for this certificate, but accepts the message anyway for consistency. (The Signaling Controller always sends this certificate for an unprovisioned CTA.)
  • a technician at the repair facility After an IPSec ESP session is established, as shown at 1026, a technician at the repair facility then calls up the CSR and explains that the CTA has now been repaired and should be configured back with the owner's certificate, as shown at 1028.
  • the CSR enters this request into the provisioning CA, as shown at 1030, which sends the CTA a certificate, as shown at 1032.
  • the CSR has to determine the unprovisioned IP address of the calling CTA and enter it into the provisioning CA. This allows the provisioning CA to find the CTA and send it the certificate. At this point, the CTA is fully provisioned for its owner and will work in the provisioned state, once moved back to the HFC segment, where it is already provisioned. A verbal indication is sent as shown at 1034.
  • the present invention provides a method and apparatus for using a manufacturer installed certificate to authenticate a cable telephony adapter. 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.

Abstract

System for using a manufacturer issued certificate to authenticate a CTA device during registration with an IP telephony network. In response to providing the manufacturer issued certificate, the issuance of another certificate allows the CTA to be provisioned by a specific IP telephony network. The system includes a method of operating a cable telephony adapter in an IP telephony network. The method includes steps of storing a manufacturer issued certificate in the cable telephony adapter, providing the manufacturer issued certificate to the telephony network, receiving a network issued certificate, and registering for telephony services with the telephony network using the network issued certificate.

Description

BUILT-IN MANUFACTURER'S CERTIFICATES FOR A CABLE TELEPHONY ADAPTER TO PROVIDE DEVICE AND SERVICE
CERTIFICATION
CROSS-REFERENCES TO RELATED APPLICATIONS This application claims priority from co-pending U.S. Provisional Patent Application 60/128,772 (hereinafter '"772" ) filed on April 9, 1999, the disclosure of which is incorporated in its entirety herein for all purposes.
FIELD OF THE INVENTION This invention relates generally to the field of network telephony, and more particularly, to a system for registering a telephony device with a telephony network.
BACKGROUND OF THE INVENTION In IP telephony systems, a cable telephony adapter (CTA) device is used to allow a user to send and receive information in secure transactions over an IP telephony network. In typical operation, a series of signaling messages are exchanged that register the CTA device with the IP telephony network before a secure channel with another user can be established.
Therefore, there is a need to authenticate the CTA device. The authentication provides protocol security and allows the IP telephony network to authenticate the identity of the CTA device. The CTA should be authenticated from the very beginning of the provisioning process. Otherwise the provisioning process would be open to additional denial of service attacks - since some provisioning exchanges can be forged. In addition, it is desirable for the service provider to cryptographically identify the CTA device - to make sure that only authorized devices are allowed in its IP Telephony network. If only the subscriber - but not the CTA device itself- were authenticated, this would not be possible.
SUMMARY OF THE INVENTION The present invention includes a system for using a manufacturer issued certificate to authenticate a CTA device during registration with an IP telephony network. In response to providing the manufacturer issued certificate, the issuance of another certificate allows the CTA to authenticate itself with a specific IP telephony network. As a result, the IP telephony network does not need to keep track of CTA hardware identifiers when outside of the provisioning system.
In one embodiment of the present invention a method of operating a cable telephony adapter in an IP telephony network is provided. The method includes steps of storing a manufacturer issued certificate in the cable telephony adapter, providing the manufacturer issued certificate to the telephony network, receiving a network issued certificate, and registering for telephony services with the telephony network using the network issued certificate.
In another embodiment of the present invention a cable telephony adapter for interfacing a user to a telephony network is provided. The cable telephony adapter includes a telephony network interface having logic to couple to the telephony network and a user interface having logic to couple to a user device. The cable telephony adapter also includes a cryptographic module having logic to store a manufacturer issued certificate and a processor coupled to the telephony network interface and the cryptographic module, and having logic to use the manufacturer issued certificate to obtain a network issued certificate. 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 portion of a telephony network including a CTA containing a manufacturer issued certificate in accordance with the present invention.
FIG. 2 shows an exemplary embodiment of a CTA constructed in accordance with the present invention; FIG. 3A shows an HFC access state machine diagram for a CTA constructed in accordance with the present invention;
FIG. 3B shows a telephony access state machine diagram for a CTA constructed in accordance with the present invention; FIG. 4 shows a messaging diagram for provisioning a CTA in accordance with the present invention;
FIG. 5 shows a method for provisioning a CTA using the messages of FIG. 4;
FIG. 6 shows a messaging diagram for de-provisioning a CTA in accordance with the present invention;
FIG. 7 shows a messaging diagram for implementing change of service for a CTA in accordance with the present invention;
FIG. 8 shows a messaging diagram for moving a CTA to a different HFC segment in accordance with the present invention; FIG. 9 shows a method for moving a CTA to a different HFC segment using the messages of FIG. 8; and
FIG. 10 shows a messaging diagram for activating a CTA after repair in accordance with the present invention.
DESCRIPTION OF THE SPECIFIC EMBODIMENTS
FIG. 1 shows a portion of a telephony network 100 including a CTA 102 containing one or more manufacturer issued certificates in accordance with the present invention. The 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, used to control the CTA's access to the telephony network. A key distribution center (KDC) 112 issues Kerberos tickets, which are in turn used to generate sub-keys for secure connection protocols, such as the Internet protocol security (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 (CA) 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. FIG. 2 shows an exemplary embodiment of the CTA 102 constructed in accordance with the present invention. The CTA 102 includes a cable interface (I/F) 202 which can be coupled to the telephony network at 204, and a user I/F 206 which can be coupled to a user at 208. The CTA 102 also includes a processor 210, a memory 212 and a cryptographic module 214.
The processor 210 is coupled to the cable I/F 202, as shown at 216, to provide decryption and encryption of information received and transmitted on the telephony network. As a result, the connection to the telephony network at line 204 carries secure encrypted information, while a connection between the cable I/F and the user I/F, as shown at line 218, carries unencrypted information. The unencrypted information is commonly referred to as clear information and extends back to the user on line 208.
The cryptographic module 214 is coupled to the processor module 210 and includes a public/private key pair that may be used to provide secured encrypted communication between the CTA 102 and the telephony network. The cryptographic module also includes a permanent device ID that is provided by the manufacturer that can be used to identify the device. This permanent device ID and the public key are embedded inside the manufacturer issued CTA certificate. The processor 210 can access the memory 212 to store CTA operating parameters, received telephony network parameters, or other cryptographic information used during operation of the CTA.
FIGS. 3 A and 3B show two separate provisioning state machines that are performed by the CTA 102. FIG. 3 A shows an access state machine diagram 300 for HFC access provisioning. FIG. 3B shows a telephony state machine diagram 302 for telephony access provisioning. Operation of the state machines are described in the following sections.
The states in the HFC access state machine 300 are: (304) HFC Not Configured - In this state the CTA is not provisioned and has not yet tried to register with the HFC head-end. (306) Unprovisioned HFC Access - In this state the CTA is registered with the HFC head-end, but there is no customer account set up. One reason the CTA was allowed to register, is so that it can get access to the CSR to get provisioned in both the telephony and HFC networks. (308) Fully Registered with HFC - In this state the CTA is registered in the HFC network's authorization database. However, the CTA's internal state does not yet permit it to send packets anywhere within the telephony network. In order to get to this state, the CTA customer account was set up in the telephony network. The Provisioning CA in the telephony network has notified the HFC head-end that
CTA access to the telephony network should be fully enabled. Alternatively, the CTA is integrated with general purpose Cable Modem access. The Cable Modem has been registered for HFC access to some non-telephony network services (e.g. Internet access). (310) Provisioned HFC Access - In this state the CTA that was fully registered with
HFC was rebooted and is now given full access to the telephony network or some other network services.
The states in the telephony access state machine 302 are: (312) Telephony I/F Not Configured - In this state the CTA is not provisioned with the telephony network and has not yet tried to register with the telephony network.
(314) Unprovisioned Telephony Access - To get to this state, the CTA performed a public key initial authentication in Kerberos (PKLNIT) exchange with the manufacturer issued certificate stored in the cryptographic module 214. This grants the CTA the right to make a phone call to the CSR and maybe to call 911. (316) Unprovisioned Telephony Signaling Security- To get to this state, the unprovisioned CTA went off-hook, at which time it used a Kerberos ticket from the PKLNIT exchange to establish a set of keys for use with IPSec ESP. IPSec ESP sessions will be used for signaling messages with the Signaling Controller, the CSR's CTA or Telephony Gateway and possibly with some additional Telephony Network Servers.
(317) CSR Call in progress - In this state an unprovisioned call to the CSR allows voice data to be exchanged using a secure protocol. To get to this state, the unprovisioned CTA exchanged signaling messages with the Signaling Controller over IPSec ESP and in the process got a key from the Signaling Controller for encrypting all communications with the CSR's CTA.
(318) Received Network Operator-Issued Certificate - To get to this state, the CTA customer picked up the phone and called the CSR. The customer provided information such as the name, address, and credit card number to the CSR. The CSR entered this information into a database. As a result, both the Telephony Network and the HFC Network were reconfigured to allow access to this customer, and a Network Operator-issued X.509 certificate was sent down to the CTA. In this state, the CTA is fully provisioned for the telephony service, but can't yet use it until it reboots.
(320) Provisioned Telephony Access - To get to this state the CTA got its Network Operator-issued certificate, it was rebooted, and will next attempt a PKLNIT exchange with the new certificate that should grant it the ability to make telephone calls, based on the subscribed service options. In the case where the CTA's privileges were revoked (perhaps the customer simply discontinued service), a
PKLNIT exchange with the Network Operator-issued certificate will fail. That will cause the CTA to go back to the Telephony I/F Not Configured state, where the CTA may get provisioned again. (322) Provisioned Access with Ticket - To get to this state the CTA performed a PKLNIT exchange with the new certificate and was granted the ability to make telephone calls, based on the subscribed service options. (324) Provisioned Telephony Signaling Security - To get to this state the CTA performed a Kerberos AP Req/Rep exchange with the signaling controller and set up IPSec Security Associations to protect all signaling messages between them. (326) Provisioned Call in progress - In this state a provisioned call allows voice data to be exchanged using a secure protocol. To get to this state, the CTA exchanged signaling messages with the Signaling Controller over IPSec ESP and in the process got a key from the Signaling Controller for encrypting all communications with the other CTA.
CTA Provisioning
The following is a description of the keys and certificates that may be provisioned at the CTA in accordance with the present invention. In one embodiment of the present invention, items 1, 3 and 5 are stored in the cryptographic module 214 and items 2, 4 are stored in the cryptographic module 214 or the memory 212.
1. An RSA key pair that is installed at the factory 2. An X.509 certificate issued by a network operator during the provisioning phase for the CTA RSA key pair. This certificate is good only for a particular network operator.
3. An X.509 certificate issued by the manufacturer and normally installed at the factory. This certificate is good for the lifetime of the CTA.
4. A manufacturer's certificate signed by a root CA. This certificate is normally installed at the factory, but may be embedded in software downloaded while online. This certificate should be valid for at least the expected lifetime of the CTA.
5. A root public key used by the CTA to verify network operator's certificate that it obtains during provisioning.
Provisioning Scenarios
A variety of provisioning scenarios are herein described for provisioning a CTA in accordance with the present invention. These specific provisioning scenarios are assuming that the KDC and the Signaling Controller are co-located on the same host. However, in general this invention is not limited to specific physical locations of the KDC and the Signaling Controller and their co-location on the same host is not required.
Initial Customer Registration FIG. 4 shows a message exchange diagram 400 illustrating how messages are exchanged between the components of the telephony network 100, to achieve initial customer registration in accordance with the present invention. The exchange diagram 400 shows messages transmitted or received at the CTA/T A/customer 104/102 at line 404, the HFC head-end 106 at line 406, the KDC 112 and Signaling Controller 116 at line 408, the CSR center 116 at line 410, the provisioning CA 118 at line 412 and the billing host 120 at line 414.
FIG. 5 shows a flow diagram 500 illustrating the process of initial customer registration utilizing a CTA with a manufacturer issued certificate and messages shown in FIG. 4 in accordance with the present invention. At block 501, the CTA coupled to the HFC includes a manufacturer issued certificate in accordance with the present invention.
At block 502 messages are exchanged between the CTA and the HFC head-end to initialize unprovisioned HFC access. These messages are shown in FIG. 4 at 416. In this block, the CTA receives a code image from the HFC head-end that includes the Network Operator Certificate. This certificate will later be used by the CTA to validate both the KDC's certificate and the CTA's own certificate issued by the network operator. The standard DOCSIS registration process for a cable modem is utilized in the case of an integrated CTA or for attached Customer Premises Equipment (CPE) in the case of a telephony adapter (TA). Since the CTA (or TA) is not provisioned at this point, it is assigned an unprovisioned IP address. This restricts the CTA to exchanging messages with the following hosts (IP addresses):
- Local Signaling Controller (110) - CSR (116)
- Provisioning C A (118)
At block 504, a Kerberos Ticket is obtained with PKLNIT as shown in FIG. 4 at 418. This is a standard PKLNIT exchange, for example, as described in section 5.2.2 of the '772 provisional patent application. The certificate used by the CTA during the PKLNIT is one that was installed in the factory and signed by the manufacturer. This certificate contains the CTA MAC address, which may be verified by the KDC. In one embodiment, it is recommended that the KDC checks with the HFC head-end to see if the IP address is valid and if the MAC address (in the certificate) corresponds to that IP address and has not been marked as "bad" at the HFC head-end. It is possible that the HFC head-end employs some sort of a physical layer cloning detection scheme that may identified the current CTA unit as a clone. The CTA manufacturer certificate sent in the PKLNIT request is also required in order for the Signaling Controller to verify the signature on the CTA certificate. The CTA also verifies the KDC signature and certificate during this step - the KDC certificate is verified with the previously obtained Network Operator Certificate.
The obtained Kerberos ticket has additional information, which restricts the CTA to telephone calls to only a single destination - the CSR. If desired, the unprovisioned CTA may also be allowed to call the 911 number. This restriction may be placed inside an authorization-data field inside the Kerberos ticket.
At block 506 the manufacturer issued CTA certificate, obtained by the Signaling Controller during the PKLNIT exchange is passed on (along with the CTA's unprovisioned IP address) to the provisioning CA as shown in FIG. 4 at 420. The CA will save this certificate and will later (when it receives customer information) use it to generate another CTA certificate, specific to this telephone network.
The IP address of the Signaling Controller (same as the IP Address of the KDC) will also be saved by the provisioning CA, so that later in the process it can inform the Signaling Controller about the telephone number of the newly provisioned CTA.
At block 508 if the manufacturer issued CTA certificate is approved by the provisioning CA, as shown at 422, an IPSec ESP Session is established, as shown at 424. This is the first action that happens when the unprovisioned CTA or TA goes off-hook, as shown at 426. The Kerberos ticket is used in AP Request (Req) and AP Reply (Rep) messages to mutually authenticate the CTA and Signaling Controller and to obtain a sub- key. This sub-key is used to derive all of the necessary keying material for IPSec ESP. For example, details of one embodiment are provided in the '772 provisional patent application at section 5.2.2 The Kerberos ticket may contain restrictions, limiting the CTA to calls to the CSR (and possibly the 911 number). The Signaling Controller must enforce these restrictions on the subsequent calls from this CTA.
At block 510, a call to the CSR is setup as shown in FIG. 4 at 428. In this step, signaling messages are exchanged in order to establish a voice connection with the CSR. This includes CTA-to-SC messages, CTA-to-CTA messages, and possibly signaling messages exchanged with another Network Server. A sub-key distribution scheme for securing CTA-to-Network Server and CTA-to-CTA links (i.e one scheme is explained in the '772 application at section 5.2.3.1) is also included in this step. All signaling messages are sent over a secure IPSec ESP layer. In another embodiment, the CTA software may be configured so that when it is in the unprovisioned state, it automatically dials the CSR as soon as the phone goes off-hook. In this case, however, the unprovisioned CTA would not be able to dial 911. If 911 access is a requirement, then the CSR telephone number should be dialed manually. At block 512, it may be necessary to obtain customer information as shown in FIG. 4 at 430. In a situation where the customer is performing his or her own installation, he or she provides customer information over the phone, including a name, address, credit card number, etc. The customer also specifies the type of desired service. The customer may also specify the desired telephone number (if such an option is available in the particular IP Telephony network).
If an installer came in with a work order number, all of the customer information and the CTA identity should already be available to the Network Operator (from an earlier phone call). At this time, the installer simply provides the work order number, and the CSR is able to find all of the corresponding customer information.
It is not necessary that a human customer service representative answers the phone on the Network Operator side. Instead, the customer or installer may be directed to a voice menu, where all of the required information is entered through the telephone keypad. This is especially convenient when an installer is calling with a work order number.
The customer information entered by the CSR goes into the provisioning CA first, as shown at 432, which assigns the customer a telephone number, appropriate for where the customer is located.
The CSR has a way to determine the calling CTA's (unprovisioned) IP address, which is also sent to the provisioning CA, along with the customer information. This information will enable the provisioning CA to send messages (described later in this scenario) to configure the calling CTA. Also, the CTA IP address is used by the provisioning CA to find the manufacturer issued certificate (received as describe above) for the calling CTA. This means that the CSR's CTA has an ability to display the IP address of the calling CTA. Alternatively, if the CSR is using a regular phone, connected to a PSTN Gateway, the CSR gets the IP address from the gateway. It is also possible, that there is an OSS connected to the CSR's CTA or PSTN Gateway and it automatically detects the IP address of the calling CTA and delivers it to the provisioning CA. At block 514, the provisioning CA updates the billing host with the customer information and the assigned telephone number, as shown in FIG. 4 at 434. At block 516, the new telephone number and the corresponding MAC address (found in the original manufacturer issued CTA certificate) are sent over from the provisioning CA to the Signaling Controller, as shown at FIG. 4 at 436. This will allow the Signaling Controller to accept a CTA certificate that contains that telephone number. The MAC address is used by the Signaling Controller (in the following message) to provision the necessary HFC resources for the CTA. At block 518, the Signaling Controller provisions the CTA for the required HFC resources, as shown in FIG. 4 at 438. The Signaling Controller sends to the HFC head-end the CTA MAC address and routing information - legal source and destination IP addresses for this CTA. Other information may also be required by the HFC head-end. After this step, the CTA is allowed to exchange messages with any node in the IP telephony network.
At block 520, the provisioning is completed after the CTA receives its new certificate, signed by the new Network Operator, and containing CTA identifying information for this telephone network (the phone ID), as shown in FIG. 4 at 440. The phone ID may be a one-way function of the phone number (e.g. SHA-1 hash), but cannot be the phone number itself (which may be unlisted). The Network Operator certificate needed to verify the new CTA certificate should already be present in the CTA. At this point the CTAjs ready to place and receive telephone calls anywhere within this telephone network. The message shown at 440 is acknowledged at 442. At block 522, the CSR gets back the telephone number from the provisioning CA (e.g. on the screen), as shown in FIG. 4 at 444, and relays it over the phone to the CTA customer, along with how the customer will be billed, etc., as shown in FIG. 4 at 446.
At block 524, the CTA is fully provisioned to use the telephony network.
De-Provisioning a CTA
FIG. 6 shows a message exchange diagram 600 illustrating how messages are exchanged between the components of the telephony network 100 to achieve de- provisioning in accordance with the present invention. The exchange diagram 600 shows messages transmitted or received from the CTA/T A/customer 104/102 at line 604, the
HFC head-end 106 at line 606, the KDC 112 and Signaling Controller 116 at line 608, the CSR center 124 at line 610, the provisioning CA 126 at line 612 and the billing host 128 at line 614.
For whatever reason, the customer may wish to discontinue currently established telephone service for the CTA. It may be that the customer is changing IP telephony providers, or moving to a new location not supported by the current IP telephony provider. In the de-provisioning scenario described below, it is assumed that the customer has a valid Kerberos ticket and has established an IPSec ESP session, as shown at 616. It will also be assumed that a call to the CSR has been performed as shown at 618. To de-provision the service, the customer simply requests termination of the service on a particular date with the CSR, as shown at 620. The CSR relays this information to the provisioning CA, as shown at 622. The provisioning CA in turn sends a termination request to the billing host, as shown at 624 and the Signaling Controller, as shown at 626. The Signaling Controller in turn propagates the termination request to the HFC head-end, as shown at 628.
Next time that the CTA tries to use its Kerberos ticket before making a phone call, the ticket will be rejected (because that phone number is no longer in the Signaling Controller's database). That will cause the CTA to try and obtain another Kerberos ticket. It will try to perform a PKLNIT exchange with its Network Operator signed certificate but will fail again. This will cause the CTA to remove the invalid certificate and transition into an unprovisioned state.
Provisioning a Previously Used CTA
The following scenario applies in cases where a new IP telephony customer is registering with a particular network operator, and the CTA he or she is using is not brand-new out of the factory. The CTA may have been used:
- by the same customer with a different network operator,
- by a different customer with the same network operator, or
- by a different customer with a different network operator. Regardless of how the CTA was used previously, the previous identity and the previous certificate issued by the old network operator is still stored in the CTA. That certificate is no longer valid and it will be assumed that the CTA was already de- provisioned, as described above.
In this case, the CTA will attempt to perform a PKLNIT exchange, using an old certificate that is no longer valid. The CTA will get an error back from the
Signaling Controller indicating that the certificate is invalid. The CTA software will then automatically remove the invalid certificate and transition into the unprovisioned state. At this time, the CTA provisioning will proceed according to the scenario described above in the section entitled Initial Customer Registration.
Change of Service FIG. 7 shows a message exchange diagram 700 illustrating how messages are exchanged between the components of the telephony network 100 to achieve change of service in accordance with the present invention. The exchange diagram 700 shows messages transmitted or received from the CTA/T A/customer 104 at line 704, the HFC head-end 106 at line 706, the KDC 112 and Signaling Controller 116 at line 708, the CSR center 124 at line 710, the provisioning CA 126 at line 712 and the billing host 128 at line 714.
In this scenario, the CTA is re-provisioned to change established service options. For example, a Caller ID service may be added or a different billing option selected, etc. In most cases, the change of service will not require the provisioning CA to issue a new CTA certificate. The one exception, is where a CTA is provisioned for an additional phone number (on another CTA port). In that case, the provisioning CA will issue a new CTA certificate containing an updated list of phone IDs for that CTA.
In the change of service scenario, the customer calls up the CSR to request the changes in service, as shown at 716. The CSR sends the update to the provisioning CA, as shown at 718, which relays that change to the Billing Host, as shown at 720 and the Signaling Controller, as shown at 722. The Signaling Controller in turn relays the change to the HFC head-end, as shown at 724. If necessary, the CTA will be issued a new certificate, as shown at 726, and may also be instructed by the HFC head-end to download a different version of the CTA software. The CTA already possesses a network operator certificate, so that it is able to perform a signature verification check along with the time validity check on the new certificate. The time validity check will not only make sure that the issued certificate had not expired - it will also make sure that the new certificate's starting time is greater than the starting time of the old certificate (i.e. the new certificate is not a replay).
Move to a Different HFC Segment
FIG. 8 shows a message exchange diagram 800 illustrating how messages are exchanged between the components of the telephony network 100 to move a CTA to a different HFC segment in accordance with the present invention. The exchange diagram 800 shows messages transmitted or received from the CTA/T A/customer 104 at line 804, the HFC head-end 106 at line 806, the KDC 112 and Signaling Controller 116 at line 808, the CSR center 124 at line 810, the provisioning CA 126 at line 812 and the billing host 128 at line 814. The exchange diagram 800 also shows messages transmitted or received from a new HFC head-end at 816, and a new Signaling Controller at 818. The new HFC head-end and new Signaling Controller are not shown in FIG. 1.
FIG. 9 shows a flow diagram 900 illustrating the process of moving a CTA to a different HFC segment utilizing messages shown in FIG. 8 in accordance with the present invention.
In this scenario the CTA owner moves to a new location, corresponding to a new HFC segment. The same IP telephony company serves the new area, but the CTA has to be assigned a new telephone number and re-provisioned for the new HFC segment. At block 902, the customer moves to a different location, still covered by the same IP Telephony company, however, the customer now has to connect to a different HFC head-end that has not been previously provisioned for this CTA. As a result, the CTA is initialized with an un-provisioned IP address by the new HFC head-end as shown in FIG. 8 at 820.
At block 904, the CTA proceeds with a PKLNIT exchange with the new Signaling Controller, using its current certificate issued by the Network Operator, as shown in FIG. 8 at 822. However, the new Signaling Controller does not recognize the certificate and the PKLNIT exchange fails.
At block 906, the CTA now falls back to a PKLNIT exchange with the new Signaling Controller using the manufacturer issued certificate and succeeds, as shown in FIG. 8 at 824.
At block 908, the manufacturer issued CTA certificate, obtained by the KDC during the PKLNIT exchange is passed on to the provisioning CA, as shown in FIG. 8 at 826. The provisioning CA doesn't actually need this certificate, because it already contains a CTA certificate (for the old HFC segment). This step is done for consistency - the KDC does this every time for an unprovisioned CTA. Along with the CTA certificate, the KDC also sends the unprovisioned IP address for that CTA. The IP address of the Signaling Controller (which may be the same as the IP address of the KDC) will also be saved by the Provisioning CA, so that it can later inform the Signaling Controller about the new Customer ID of the newly provisioned CTA.
At block 910, an IPSec ESP Session is established, as shown in FIG. 8 at 828. This is the first action that happens when the unprovisioned CTA or TA goes off- hook. A Kerberos ticket is used in the AP Request / AP Reply messages to mutually authenticate the CTA and Signaling Controller and to obtain a sub-key. This sub-key is used to derive all of the necessary keying material for IPSec ESP.
The Kerberos ticket contains restrictions, limiting the CTA to calls to the CSR (and possibly the 911 number). The new Signaling Controller must enforce these restrictions on the subsequent calls from this CTA.
At block 912, a call to CSR is setup, as shown in FIG. 8 at 830. In this step, signaling messages are exchanged, in order to establish a voice connection with a CSR. This includes CTA-to-SC messages, CTA-to-CTA messages, and possibly signaling messages exchanged with another Network Server. The key distribution for securing CTA-to-Network Server and CTA-to-CTA links is also included in this step. All signaling messages are sent over a secure IPSec ESP layer.
The CTA software may be configured, so that when it is in an unprovisioned state, it automatically dials the CSR, as soon as the phone goes off-hook. In this case, however, an unprovisioned CTA will not be able to dial 911. If that is a requirement, then the CSR telephone number should be dialed manually.
At block 914, the customer information is updated, as shown in FIG. 8 at 832. The CSR will send (manually enter) the provisioning CA the old telephone number and the new customer information, as shown in FIG. 8 at 834. The provisioning CA will update the billing host with the new customer information and with both the old and the new customer ID, based on the new customer location, as shown in FIG. 8 at 836.
The CSR must have a way to determine the calling CTA's (unprovisioned) IP address, which is also sent to the provisioning CA, along with the customer information. This information will enable the provisioning CA to send messages (described later in this scenario) to configure the calling CTA. The CTA IP address is also used by the provisioning CA to find the manufacturer issued certificate for the calling CTA.
This means that the CSR's CTA must have an ability to display the IP address of the calling CTA. Alternatively, if the CSR is using a regular phone, connected to a Public Switched Telephone Network (PSTN) Gateway, the CSR gets the IP address from the gateway. It is also possible, that there is an OSS connected to the CSR's CTA or the PSTN Gateway and it automatically detects the IP address of the calling CTA and delivers it to the provisioning CA. At block 916, the Old Signaling Controller is notified that the old customer
ID (phone number) is no longer authorized and should be removed from its database, as shown in FIG. 8 at 838. The corresponding MAC address (found in the original manufacturer issued CTA certificate) is also sent. This MAC address is used by the Signaling Controller to remove the HFC resources for this CTA in the old HFC head-end. At block 918, the old HFC head-end is notified by the old Signaling
Controller that the CTA MAC address is no longer provisioned for that particular HFC segment, as shown in FIG. 8 at 840.
At block 920, the new phone number and the corresponding MAC are sent over from the provisioning CA to the new Signaling Controller, as shown in FIG. 8 at 842. This will allow the new Signaling Controller to accept a CTA certificate that contains the corresponding phone ID. The MAC address is used by the new Signaling Controller (in the following message) to provision the necessary HFC resources for the CTA.
At block 922, the new Signaling Controller provisions the CTA for the required HFC resources. It sends to the new HFC head-end the CTA MAC address and routing information - legal source and destination IP addresses for this CTA, as shown in FIG. 8 at 844. Other information may also be required by the new HFC head-end.
After this step, the CTA is allowed to exchange messages with any node in the IP telephony network. At block 924, the provisioning is completed in this step after the CTA receives its new certificate signed by the new Network Operator and containing the new phone ID, as shown in FIG. 8 at 846. Now, the CTA is ready to place and receive telephone calls anywhere within this telephone network.
At block 926, the CSR gets the new telephone number from the provisioning CA, as shown in FIG. 8 at 848, and relays it over the phone to the CTA customer, as shown in FIG. 8 at 850. Repairing a CTA
When a CTA needs repair, certificates provided by the present invention can be used to repair and test the CTA, and thereafter, allow the customer to provision the repaired CTA for use in a telephony network. The following steps for repair are:
- A damaged CTA is shipped to a repair facility.
- After the CTA is fixed, it needs to be tested. To test the CTA, it is re-provisioned for a special account associated with the repair facility and undergoes testing. This insures that the customer does not get billed for the telephone services that are being tested by the repair facility.
- To re-provision the CTA for testing, a test engineer removes the customer certificate in the CTA, possibly through the front panel controls on the CTA. The customer is still provisioned in the telephony network and the certificate can always be loaded back from the network, as described in a previous section. - The CTA enters the unprovisioned state (even though the customer is still provisioned) and will follow the provisioning steps outlined above for Initial customer registration using the repair facility certificate.
- The CTA is now provisioned for the repair facility to allowed the required testing to take place. The repair facility certificate should have a short validity period (a few days or even a few hours).
Replacing a CTA
It is assumed in this scenario that the original CTA was broken and shipped to a repair facility. Meanwhile, a different CTA was sent to the customer, so that he or she does not have to wait for the original CTA to be repaired.
In this case, the replacement CTA is provisioned as if it were a new CTA - see figures 4 and 5.
CTA Returns from Repair In this scenario, a CTA was repaired and tested in the repair facility.
During the testing phase, the CTA certificate was replaced with the one for the repair facility. After the testing was completed, the test certificate is either removed from the CTA using the front panel or the CTA underwent the full de-provisioning process illustrated in FIG. 6. In any event the repair facility certificate expires in a relatively short time.
FIG. 10 shows a message exchange diagram 1000 illustrating how messages are exchanged between the components of the telephony network 100 to provision a CTA that has been returned from a repair facility. The exchange diagram 1000 shows messages transmitted or received from the CTA/T A/customer 104 at line 1004, the HFC head-end 106 at line 1006, the KDC 112 and Signaling Controller 116 at line 1008, the CSR center 124 at line 1010, the provisioning CA 126 at line 1012 and the billing host 128 at line 1014.
In the exchange diagram 1000, the CTA gets unprovisioned access to the HFC segment connected to the repair facility and attempts to initialize provisioned access, as shown at 1020. The CTA performs an unprovisioned PKLNIT exchange with the local Signaling Controller, as shown at 1022, which relays the manufacturer issued CTA certificate to the provisioning CA, as shown at 1024. In this case, the provisioning CA has no use for this certificate, but accepts the message anyway for consistency. (The Signaling Controller always sends this certificate for an unprovisioned CTA.)
After an IPSec ESP session is established, as shown at 1026, a technician at the repair facility then calls up the CSR and explains that the CTA has now been repaired and should be configured back with the owner's certificate, as shown at 1028. The CSR enters this request into the provisioning CA, as shown at 1030, which sends the CTA a certificate, as shown at 1032.
As with other provisioning scenarios, the CSR has to determine the unprovisioned IP address of the calling CTA and enter it into the provisioning CA. This allows the provisioning CA to find the CTA and send it the certificate. At this point, the CTA is fully provisioned for its owner and will work in the provisioned state, once moved back to the HFC segment, where it is already provisioned. A verbal indication is sent as shown at 1034.
The present invention provides a method and apparatus for using a manufacturer installed certificate to authenticate a cable telephony adapter. 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:
1. A method of operating a cable telephony adapter in an IP telephony network, the method comprising: storing a manufacturer issued certificate in the cable telephony adapter; providing the manufacturer issued certificate to the telephony network; receiving a network issued certificate; and registering for telephony services with the telephony network using the network issued certificate.
2. The method of claim 1, wherein the manufacturer issued certificate includes a device identifier for the cable telephony adapter and an RSA key pair.
3. The method of claim 1 , wherein the step of receiving further includes a step of storing the network issued certificate in a memory in the cable telephony adapter.
4. A cable telephony adapter for interfacing a user to a telephony network, the cable telephony adapter comprising: a telephony network interface having logic to couple to the telephony network; a user interface having logic to couple to a user device; a cryptographic module having logic to store a manufacturer issued certificate; and a processor coupled to the telephony network interface and the cryptographic module, and having logic to provide the manufacturer issued certificate to the telephony network to obtain a network issued certificate.
5. The cable telephony adapter of claim 4, further comprising a memory coupled to the processor and having logic to store the network issued certificate.
PCT/US2000/009318 1999-04-09 2000-04-07 Built-in manufacturer's certificates for a cable telephony adapter to provide device and service certification WO2000062519A2 (en)

Priority Applications (6)

Application Number Priority Date Filing Date Title
US10/296,846 US7376837B1 (en) 1999-04-09 2000-04-07 Built-in manufacturer's certificates for a cable telephony adapter to provide device and service certification
AU40792/00A AU4079200A (en) 1999-04-09 2000-04-07 Built-in manufacturer's certificates for a cable telephony adapter to provide device and service certification
CA002370471A CA2370471A1 (en) 1999-04-09 2000-04-07 Built-in manufacturer's certificates for a cable telephony adapter to provide device and service certification
EP00920214A EP1171989A2 (en) 1999-04-09 2000-04-07 Built-in manufacturer's certificates for a cable telephony adapter to provide device and service certification
US09/668,426 US6892308B1 (en) 1999-04-09 2000-09-22 Internet protocol telephony security architecture
US11/028,821 US20050120248A1 (en) 1999-04-09 2005-01-03 Internet protocol telephony security architecture

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12877299P 1999-04-09 1999-04-09
US60/128,772 1999-04-09

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/002174 Continuation-In-Part WO2000045539A1 (en) 1999-01-29 2000-01-28 Key management for telephone calls to protect signaling and call packets between cta's

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US09/668,426 Continuation-In-Part US6892308B1 (en) 1999-04-09 2000-09-22 Internet protocol telephony security architecture

Publications (3)

Publication Number Publication Date
WO2000062519A2 true WO2000062519A2 (en) 2000-10-19
WO2000062519A3 WO2000062519A3 (en) 2001-02-08
WO2000062519A9 WO2000062519A9 (en) 2002-02-21

Family

ID=22436900

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/US2000/009318 WO2000062519A2 (en) 1999-04-09 2000-04-07 Built-in manufacturer's certificates for a cable telephony adapter to provide device and service certification
PCT/US2000/009323 WO2000062507A1 (en) 1999-04-09 2000-04-07 Key management between a cable telephony adapter and associated signaling controller

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/US2000/009323 WO2000062507A1 (en) 1999-04-09 2000-04-07 Key management between a cable telephony adapter and associated signaling controller

Country Status (9)

Country Link
US (2) US7568223B2 (en)
EP (2) EP1171989A2 (en)
CN (1) CN1127835C (en)
AT (1) ATE313200T1 (en)
AU (2) AU4213600A (en)
CA (2) CA2365856C (en)
DE (1) DE60024800T2 (en)
HK (1) HK1045917B (en)
WO (2) WO2000062519A2 (en)

Families Citing this family (59)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000062519A2 (en) * 1999-04-09 2000-10-19 General Instrument Corporation Built-in manufacturer's certificates for a cable telephony adapter to provide device and service certification
US20030021417A1 (en) * 2000-10-20 2003-01-30 Ognjen Vasic Hidden link dynamic key manager for use in computer systems with database structure for storage of encrypted data and method for storage and retrieval of encrypted data
US6966003B1 (en) * 2001-01-12 2005-11-15 3Com Corporation System and method for switching security associations
US8156223B2 (en) * 2001-03-20 2012-04-10 Microsoft Corporation Distribution of binary executables and content from peer locations/machines
US8555062B1 (en) * 2001-03-26 2013-10-08 Access Co., Ltd. Protocol to prevent replay attacks on secured wireless transactions
US7181620B1 (en) * 2001-11-09 2007-02-20 Cisco Technology, Inc. Method and apparatus providing secure initialization of network devices using a cryptographic key distribution approach
KR100415117B1 (en) * 2002-03-04 2004-01-13 삼성전자주식회사 Apparatus and method for called compulsive on multi call into internet protocol phone in an internet protocol telephony system
US7565537B2 (en) * 2002-06-10 2009-07-21 Microsoft Corporation Secure key exchange with mutual authentication
FR2845226B1 (en) * 2002-10-01 2004-12-10 France Telecom METHOD AND INSTALLATION FOR CONTROLLING THE IDENTITY OF THE TRANSMITTER OF A TELEPHONE CALL ON AN INTERNET NETWORK AND TELEPHONY TERMINAL FOR SUCH AN INSTALLATION
JP4397675B2 (en) * 2003-11-12 2010-01-13 株式会社日立製作所 Computer system
JP4559794B2 (en) * 2004-06-24 2010-10-13 株式会社東芝 Microprocessor
US7748032B2 (en) * 2004-09-30 2010-06-29 Citrix Systems, Inc. Method and apparatus for associating tickets in a ticket hierarchy
US7711835B2 (en) 2004-09-30 2010-05-04 Citrix Systems, Inc. Method and apparatus for reducing disclosure of proprietary data in a networked environment
US8613048B2 (en) 2004-09-30 2013-12-17 Citrix Systems, Inc. Method and apparatus for providing authorized remote access to application sessions
US7464267B2 (en) * 2004-11-01 2008-12-09 Innomedia Pte Ltd. System and method for secure transmission of RTP packets
US7917764B2 (en) * 2005-01-24 2011-03-29 Panasonic Corporation Signature generation device and signature verification device
US7890634B2 (en) 2005-03-18 2011-02-15 Microsoft Corporation Scalable session management
US7650505B1 (en) * 2005-06-17 2010-01-19 Sun Microsystems, Inc. Methods and apparatus for persistence of authentication and authorization for a multi-tenant internet hosted site using cookies
US7545810B2 (en) * 2005-07-01 2009-06-09 Cisco Technology, Inc. Approaches for switching transport protocol connection keys
WO2007062392A2 (en) * 2005-11-23 2007-05-31 Riverain Medical Group, Llc Computer-aided diagnosis using dual-energy subtraction images
CN101371550B (en) * 2005-11-30 2012-01-25 意大利电信股份公司 Method and system for automatically and freely providing user of mobile communication terminal with service access warrant of on-line service
KR100652017B1 (en) * 2005-12-08 2006-12-01 한국전자통신연구원 Method for security of docsis cable modem against physical security attacks
US7706381B2 (en) * 2006-01-10 2010-04-27 Cisco Technology, Inc. Approaches for switching transport protocol connection keys
US8140851B1 (en) * 2006-02-24 2012-03-20 Cisco Technology, Inc. Approaches for automatically switching message authentication keys
US8732279B2 (en) * 2006-08-18 2014-05-20 Cisco Technology, Inc. Secure network deployment
US8533846B2 (en) 2006-11-08 2013-09-10 Citrix Systems, Inc. Method and system for dynamically associating access rights with a resource
CA2571891C (en) * 2006-12-21 2015-11-24 Bce Inc. Device authentication and secure channel management for peer-to-peer initiated communications
CN101790867A (en) * 2007-04-30 2010-07-28 惠普开发有限公司 The system and method for distribution node configuration information
AU2008301284B2 (en) 2007-09-17 2013-05-09 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement in a telecommunication system
US8171483B2 (en) 2007-10-20 2012-05-01 Citrix Systems, Inc. Method and system for communicating between isolation environments
CN101286840B (en) * 2008-05-29 2014-07-30 西安西电捷通无线网络通信股份有限公司 Key distributing method and system using public key cryptographic technique
US7877503B2 (en) * 2008-07-02 2011-01-25 Verizon Patent And Licensing Inc. Method and system for an intercept chain of custody protocol
US8776238B2 (en) * 2008-07-16 2014-07-08 International Business Machines Corporation Verifying certificate use
KR101255987B1 (en) * 2008-12-22 2013-04-17 한국전자통신연구원 Paring method between SM and TP in downloadable conditional access system, Setopbox and Authentication device using this
US20110013762A1 (en) * 2009-07-18 2011-01-20 Gregg Bieser Notification apparatus & method
US8683194B2 (en) 2009-09-30 2014-03-25 Orange Method and devices for secure communications in a telecommunications network
US20110302416A1 (en) * 2010-03-15 2011-12-08 Bigband Networks Inc. Method and system for secured communication in a non-ctms environment
US8347080B2 (en) 2010-05-10 2013-01-01 Research In Motion Limited System and method for multi-certificate and certificate authority strategy
EP2387262B1 (en) * 2010-05-10 2015-04-29 BlackBerry Limited System and method for multi-certificate and certificate authority strategy
US8566596B2 (en) * 2010-08-24 2013-10-22 Cisco Technology, Inc. Pre-association mechanism to provide detailed description of wireless services
US8938619B2 (en) * 2010-12-29 2015-01-20 Adobe Systems Incorporated System and method for decrypting content samples including distinct encryption chains
US8843737B2 (en) * 2011-07-24 2014-09-23 Telefonaktiebolaget L M Ericsson (Publ) Enhanced approach for transmission control protocol authentication option (TCP-AO) with key management protocols (KMPS)
WO2013061614A2 (en) * 2011-10-28 2013-05-02 Nec Corporation Secure method for mtc device triggering
US9026784B2 (en) * 2012-01-26 2015-05-05 Mcafee, Inc. System and method for innovative management of transport layer security session tickets in a network environment
US9762569B2 (en) * 2012-10-15 2017-09-12 Nokia Solutions And Networks Oy Network authentication
US9515996B1 (en) * 2013-06-28 2016-12-06 EMC IP Holding Company LLC Distributed password-based authentication in a public key cryptography authentication system
US9553982B2 (en) * 2013-07-06 2017-01-24 Newvoicemedia, Ltd. System and methods for tamper proof interaction recording and timestamping
JP6278651B2 (en) * 2013-09-27 2018-02-14 キヤノン株式会社 Network system, management server system, control method and program
FR3018371B1 (en) 2014-03-10 2016-05-06 Commissariat Energie Atomique REMOTE KEY DATA ENCRYPTION / ENCRYPTION METHOD AND SYSTEM AND PRIOR CHECK CHECK
US20170163607A1 (en) * 2015-12-03 2017-06-08 Microsoft Technology Licensing, Llc Establishing a Communication Event Using Secure Signalling
US10009380B2 (en) 2016-01-08 2018-06-26 Secureworks Corp. Systems and methods for security configuration
US10263788B2 (en) * 2016-01-08 2019-04-16 Dell Products, Lp Systems and methods for providing a man-in-the-middle proxy
US20180123782A1 (en) * 2016-10-27 2018-05-03 Motorola Solutions, Inc. Method for secret origination service to distribute a shared secret
EP3501654B1 (en) 2017-12-22 2021-08-25 Tecan Trading Ag Pipetting apparatus with a pipette tube and method for detecting a liquid within an intermediate section of pipette tube
US10771269B2 (en) * 2018-03-09 2020-09-08 Cisco Technology, Inc. Automated intelligent node for hybrid fiber-coaxial (HFC) networks
US10630467B1 (en) * 2019-01-04 2020-04-21 Blue Ridge Networks, Inc. Methods and apparatus for quantum-resistant network communication
US11063753B2 (en) 2019-03-20 2021-07-13 Arris Enterprises Llc Secure distribution of device key sets over a network
US11743242B2 (en) * 2020-07-27 2023-08-29 Charter Communications Operating, Llc Establishing an encrypted communications channel without prior knowledge of the encryption key
CN112492004B (en) * 2020-11-17 2023-02-17 深圳市晨北科技有限公司 Method, device, system and storage medium for establishing local communication link

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5867495A (en) * 1996-11-18 1999-02-02 Mci Communications Corporations System, method and article of manufacture for communications utilizing calling, plans in a hybrid network

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5235642A (en) 1992-07-21 1993-08-10 Digital Equipment Corporation Access control subsystem and method for distributed computer system using locally cached authentication credentials
EP0720796B1 (en) * 1993-09-20 1997-07-16 International Business Machines Corporation System and method for changing the key or password in a secure distributed communications network
US5544322A (en) * 1994-05-09 1996-08-06 International Business Machines Corporation System and method for policy-based inter-realm authentication within a distributed processing system
IL113259A (en) * 1995-04-05 2001-03-19 Diversinet Corp Apparatus and method for safe communication handshake and data transfer
US5602918A (en) * 1995-12-22 1997-02-11 Virtual Open Network Environment Corp. Application level security system and method
SE506775C2 (en) * 1996-06-04 1998-02-09 Ericsson Telefon Ab L M Ways and devices for simultaneous telephone and Internet connection on a telephone line
US5796830A (en) * 1996-07-29 1998-08-18 International Business Machines Corporation Interoperable cryptographic key recovery system
US5864665A (en) * 1996-08-20 1999-01-26 International Business Machines Corporation Auditing login activity in a distributed computing environment
US5917817A (en) 1996-12-06 1999-06-29 International Business Machines Corporation User invocation of services in public switched telephone network via parallel data networks
US5923756A (en) * 1997-02-12 1999-07-13 Gte Laboratories Incorporated Method for providing secure remote command execution over an insecure computer network
AP9901678A0 (en) 1997-04-15 1999-12-31 Mci Worldcom Inc Method and article of manufacture for switched telephony communication.
US5999612A (en) 1997-05-27 1999-12-07 International Business Machines Corporation Integrated telephony and data services over cable networks
WO2000062519A2 (en) * 1999-04-09 2000-10-19 General Instrument Corporation Built-in manufacturer's certificates for a cable telephony adapter to provide device and service certification
EP1320975B1 (en) * 2000-09-22 2005-12-07 General Instrument Corporation Internet protocol telephony security architecture
US20030163693A1 (en) * 2002-02-28 2003-08-28 General Instrument Corporation Detection of duplicate client identities in a communication system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5867495A (en) * 1996-11-18 1999-02-02 Mci Communications Corporations System, method and article of manufacture for communications utilizing calling, plans in a hybrid network

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
CEHRI PAQUET: "Motorola announces IP telephony via cable networks" COMPUTERWORLD, 5 May 1998 (1998-05-05), XP002147950 Available on Internet URL:<http://www.cw.com.hk/Analysis/a980506 001.htm> 6/05/1998 *
CISCO: "Cisco Announces New cable Broadband access product to support integraded data, voice and video" AVAILABLE FROM INTERNET:<URL:HTTP://CIO.CISCO.COM/WARP/PU BLIC/146/PRESSROOM/1999/JAN99/10.HTML, 8 January 1999 (1999-01-08), XP002147934 *
NORTEL NETWORKS: "IP Telephony" CABLENET'98, 1998, XP002147949 Available on Internet URL:<http://www.cablenet.org/CN98/apps/Nor t_teleph_col.pdf> 1998 *

Also Published As

Publication number Publication date
CN1346563A (en) 2002-04-24
CA2365856A1 (en) 2000-10-19
CA2365856C (en) 2011-11-01
HK1045917A1 (en) 2002-12-13
ATE313200T1 (en) 2005-12-15
WO2000062507A1 (en) 2000-10-19
AU4079200A (en) 2000-11-14
AU4213600A (en) 2000-11-14
DE60024800D1 (en) 2006-01-19
EP1171989A2 (en) 2002-01-16
US20090323954A1 (en) 2009-12-31
DE60024800T2 (en) 2006-07-06
HK1045917B (en) 2004-09-10
US8544077B2 (en) 2013-09-24
EP1169833B1 (en) 2005-12-14
WO2000062519A3 (en) 2001-02-08
CA2370471A1 (en) 2000-10-19
CN1127835C (en) 2003-11-12
US7568223B2 (en) 2009-07-28
WO2000062519A9 (en) 2002-02-21
EP1169833A1 (en) 2002-01-09
US20050027985A1 (en) 2005-02-03

Similar Documents

Publication Publication Date Title
WO2000062519A2 (en) Built-in manufacturer&#39;s certificates for a cable telephony adapter to provide device and service certification
AU2004307800B2 (en) Method for managing the security of applications with a security module
CN109547464B (en) Method and apparatus for storing and executing access control client
US9059841B2 (en) Auto-discovery of a non-advertised public network address
CN109417545B (en) Method, security module, mobile terminal and medium for downloading a network access profile
CN102668497B (en) Method and device allowing secure communication in a telecommunications protected against denial of service (Dos) and flooding attack
KR20010108150A (en) Authentication enforcement using decryption and authentication in a single transaction in a secure microprocessor
US20040172536A1 (en) Method for authentication between a portable telecommunication object and a public access terminal
EP2547051B1 (en) Confidential communication method using vpn, a system and program for the same, and memory media for program therefor
WO2004032415A1 (en) Method and apparatus enabling reauthentication in a cellular communication system
WO2018096311A1 (en) Handset identifier verification
JP2005142973A (en) Network connection system and network connection method
US7376837B1 (en) Built-in manufacturer&#39;s certificates for a cable telephony adapter to provide device and service certification
US20130183934A1 (en) Methods for initializing and/or activating at least one user account for carrying out a transaction, as well as terminal device
WO2000052905A2 (en) Method and apparatus for enhanced security in a broadband telephony network
CN101179570A (en) Method for binding link layer information based on network access authentication information carrying protocol
EP1494395A1 (en) Method and authentication module for providing access to a target network via a wireless local area network WLAN
Bagnulo et al. Providing Authentication & Authorization mechanisms for active service charging
TWI246300B (en) Method and apparatus enabling reauthentication in a cellular communication system
JP2004023166A (en) Mobile communication service system
KR20050088988A (en) Method for identifying a communications terminal

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref country code: US

Ref document number: 2000 668426

Date of ref document: 20000922

Kind code of ref document: A

Format of ref document f/p: F

AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
ENP Entry into the national phase

Ref document number: 2370471

Country of ref document: CA

Ref country code: CA

Ref document number: 2370471

Kind code of ref document: A

Format of ref document f/p: F

WWE Wipo information: entry into national phase

Ref document number: 2000920214

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2000920214

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

AK Designated states

Kind code of ref document: C2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: C2

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

COP Corrected version of pamphlet

Free format text: PAGES 1/10-10/10, DRAWINGS, REPLACED BY NEW PAGES 1/11-11/11; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Ref document number: 2000920214

Country of ref document: EP

DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)