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.
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
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:
- keys do not ever have to be seen by humans,
- keys can be updated frequently without manual intervention, and
- new devices can appear on the network and be automatically secured.
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
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.