IPfonix logo

KDC Features

IPfonix, Inc. KDCs:

Run on inexpensive off-the-shelf PC-class hardware
The hardware requirements for our KDCs are minimal. Any modern computer should easily be able to run the KDC software and support hundreds of thousands (or millions) of clients. An off-the-shelf inexpensive PC with a single 1.8 GHz Athlon easily supports millions of clients. Disk requirements are negligible: the KDC does use the disk for logfiles, which may consume as much as a few GB, depending on the debug level chosen. The KDC runs easily in less than 128 MB. Networks with large numbers of clients may require somewhat more memory. 512 MB should be more than adequate for all conceivable networks.

Support millions of client devices off a single KDC
Because the CPU, disk, and memory requirements are so small, a single PC-class machine can be used to support even very large subscriber bases constituting millions of clients. Because the PacketCable system ensures that there is a minimal restart avalanche, a single small KDC can support the network even after a widespread power failure.

Support IPv6
Although PacketCable and CableHome do not specify exactly how PacketCable and CableHome should work on IPv6 networks, from a security standpoint the changes needed are rather minimal and the extensions quite simple. The IPfonix, Inc. KDC therefore supports use of extended MTAs and Portal Service Devices that have been adapted to work on IPv6 access networks.

Implement a “pseudo-provisioning server” to allow MTAs to be deployed without a true PacketCable Provisioning Server present in the operator network
PacketCable networks are required to contain a provisioning server element to communicate with subscriber devices and with backoffice provisioning elements. Many MSOs are reluctant to purchase a complete PacketCable provisioning system, since they typically already have invested in a provisioning system for their cable modems. In addition, many vendors of cable modem provisioning systems do not offer a PacketCable-compliant front end.

Allow peering for automatic failover with key retention
Multiple KDCs can be joined in a peering group that maintains a consistent view of keying state across the KDCs. This allows MSOs to deploy networks with fully automated dynamic service keys and automatic failover with retention of the keying information in the event that a KDC goes down.

To help such MSOs deploy PacketCable, the IPfonix, Inc. PacketCable KDC includes a module that interacts with a booting MTA as if it were a PacketCable provisioning server. As far as the MTA is concerned, it is communicating with a real PacketCable provisioning server. The pseudo-ps module sends the correct messages to the MTA to allow it to boot securely, under the control of SNMPv3. The pseudo-ps also leaks the keys to the backend provisioning system, and will proxy requests from the backend provisioning system to the MTA once it has booted. This allows an operator to deploy a network whose interfaces to the MTA conform to the PacketCable security requirements, but without the expense of purchasing a complete provisioning system solely for this purpose.

Implement PKCROSS for multi-realm deployments and secure inter-MSO VoIP calls
PacketCable defines a system for securing signaling communication between networks in a dynamic manner using PKCROSS (which is a variant of PKINIT as used by subscriber clients). The PacketCable security specification defines precisely how PKCROSS is to work, and the IPfonix, Inc. KDC implements PKCROSS as required by the specification. The same PKCROSS system can be used by large MSOs who wish to deploy telephony on a region-by-region (or city-by-city) basis using different administrative domains in the regions (or cities). Note that it is important for signaling between networks to be secured, because once data leaves a network, the operator no longer can control the route of the packet, so there is no guarantee that it will not be accessible to a third party. Signaling should never be exposed to third parties; therefore it should travel only over connections that have been secured by some method that is impervious to man-in-the-middle and other attacks.

Fully support Dynamic Service Keying -- allows MSOs to add new devices to the core network securely and fully automatically
Configuring the keys for a network is typically a complex, time-consuming and error-prone task. It also is much less secure than it should be, partly because manual configuration exposes keys to the personnel who must input the keys into the various devices (and, in the process, choose either easy-to-remember keys or write the keys down), and partly because, once configured, the pain of reconfiguration is simply too great, with the result that the service are never changed. This exposes network operators to several attacks to which they would not be exposed if keys could be configured without any manual involvement and also changed frequently without impacting the network or personnel.

IPfonix, Inc. KDCs fully support dynamic service keying. This allows personnel to spend their time doing more interesting things than configuring keys. By using dynamic service keys:

A new device that the operator wishes to attach to the network (for example, a CMTS or CMS) can immediately obtain service keys through the KDC's Dynamic Service Keying service. This allows the new device to communicate securely with other network devices, without the need for any manual configuration (except, perhaps, inputting the IP address of the KDC on to the new device; but even this step can be avoided if the new device uses SRV lookups to find the KDC in the same manner that subscriber MTAs find the KDC).

Are highly configurable to an MSO's specific needs
Our KDCs feature more than 100 optional configuration parameters that may be used to control the detailed behaviour of the software. Although most MSOs need to change few (if any) of these parameters, they are available to tweak the KDC so that it operates exactly as the MSO requires.

Closely track PacketCable, Euro-PacketCable, IPCablecom and CableHome specifications
Although they are now stablising, in the past several non-backward-compatible features have been incorporated into the relevant security specifications. We track the changes in requirements closely, so that our KDCs implement the current versions of the specs, and provide compatibility configuration options when necessary to ensure interoperability with older equipment.

Are designed from the ground up to be robust against attack
Because KDCs are exposed to subscribers, they need to be able to handle any input that is sent to them without behaving in an unexpected manner. In particular, they must be able to handle malformed messages without falling prey to buffer overflows and other errors. Our KDCs do not use third party libraries to perform any of these functions. Our code is hand-written and does not use unprotected raw pointers or buffers at any point in the processing of received messages. Our stress-testing procedure includes a large number of tests in which malformed packets are sent to the KDC in an attempt to the software misbehave or crash.

In particular, none of the security alerts against the Microsoft or OpenSSL ASN.1 stacks apply to our KDCs. (Indeed we were quite astonished to discover that apparently these stacks use unprotected buffers that may be overflowed.)

Include support for secure deployment of PacketCable Multimedia devices
PCMM devices, like devices in ordinary PacketCable networks, can be deployed automatically and securely. Our KDCs support automatic secure deployment of PCMM Policy Servers and Application Managers.

Support the Online Certificate Status Protocol (OCSP, RFC 2560) for real-time checking of revocation status
OCSP can be used in real time to automatically check whether any certificates presented to the KDC have been revoked, before the KDC will issue a ticket to a client.

Made with Bluefish