Key Distribution Center FAQ

We find that several questions about PacketCable/CableHome KDCs in general, and the IPfonix, Inc. KDCs in particular, come up quite frequently. Here are the most-often asked questions, along with our answers. If you have other questions, please feel free to e-mail us at info@ipfonix.com.

Q To what extent do your products use the MIT Kerberos distribution?

A. They don’t use the MIT code at all. When we first decided to implement a PacketCable KDC, we investigated the amount of effort that it would take to base a fully PacketCable-compliant commercial-grade solution on the MIT code, and we decided that, while obviously not impossible, it would be more difficult than designing a product completely from scratch. Maintenance and debugging was a particular concern. There are a huge number of differences between MIT Kerberos and PacketCable’s requirements, and the more we looked at the MIT code, the more convinced we were that it was simply asking for trouble to try to base a commercial PacketCable offering on the MIT code. This is not to say that the MIT code is bad – there were simply too many differences between what it implements and what PacketCable requires for us to feel comfortable in attempting the conversion.

Q MIT Kerberos is written in C. Is your code also in C?

A. No. Our code is 100% C++. The total code base runs to approximately 70,000 lines of documented C++. We have never counted the number of classes, but it is (at least) several dozen. We have been programming in C++ since 1989 and find C++ well-suited to projects of this size. The template and exception facilities are particularly powerful when one is considering maintenance and debugging issues (as we all know, what is the point of writing the world’s best/fastest/most elegant application if one can’t debug it or maintain it?). Whenever we had to choose between [elegance and speed] and [safety and ease of maintenance], we chose the latter. If we had the entire project to do over again, we would make all the same choices regarding language and emphasis. We believe that all those decisions have served us well.

Q So why not Java?

A The only real advantage of Java that we can see is the portability of the code. However, by writing C++ code that does not rely on OS-dependent “tricks”, one can come very close to 100% portable code, even on a project of this size. Java also has (at least in our eyes) several difficulties: the lack of templates and multiple inheritance, as well as its automatic garbage collection cause us concern. Fundamentally, though, we simply prefer C++.

Q 70,000 lines of code seems like a lot for a KDC

A. Maybe it is. But it depends on exactly what one means by “KDC”. If we simply desired an application that would interoperate with well-behaved, compliant PacketCable devices, we estimate that we could remove approximately the large majority of the code and the KDC would behave exactly as it does now in a normal, benign lab environment. However, it is important to bear two things in mind:

1. In a real-world deployment, hackers do not simulate well-behaved, compliant PacketCable devices. The KDC is a security device that is exposed to end-users, and the way to test KDC security is not to use nice, well-behaved messages – the KDC must be immune from (and must be able to report if necessary) any and all possible message to which it can be exposed, no matter how badly formed they are.

2. PacketCable has a strict set of requirements. Vendors of devices such as MTAs rely on the KDC manufacturer to tell them if their messages are in any way non-compliant. Only if the KDC is brutally honest in reporting non-compliance can the vendors of other equipment be expected to fix errors in their own code. And only by fixing errors in their code can such vendors realistically expect to be certified as compliant by bodies such as CableLabs and tComLabs.

In other words, it is in the interests of MSOs and the vendors of other equipment to ensure that the KDC has extremely thorough and robust error handling. Which is why the majority of our code is dedicated to that function, even though under most circumstances that code is “invisible”.

Q PacketCable supports interdomain security proxied via KDCs. Does your KDC implement this?

A. Yes. From our first release (in April, 2001) we have supported PKCROSS as specified and required by the PacketCable specifications.

Q Although the PacketCable and CableHome specifications are becoming more stable, changes are still made from time to time. How well do you track those?

A. We work hard to implement every change that affects the KDC within a week (or less) of a public change to the specifications. This is typically roughly two months before the certification programs require changes to be implemented.

Q I’m an MSO and I worry about the “avalanche effect”. What happens to the KDC if I have 1,000,000 customers and all their power goes off for half an hour? How long will it take your KDC to accept all those devices back on to the network?

A You may want to talk to us about the detailed answer to this question, but the short answer is that it’s not an issue. MTAs are required to store their Kerberos tickets in NVRAM. Since tickets are typically valid for between six and seven days, then the number of MTAs that would need to communicate with the KDC after a half-hour power outage is quite small (approximately 0.3% of the deployed MTAs). So if you really suffer the catastrophic event that 1,000,000 MTAs go offline for half an hour, then roughly 3,000 of those would require an exchange with the KDC on reboot. Even if you are running a single KDC (not advised – you should run two) on a mere 2GHz Athlon-class single-processor Linux machine, the KDC should be able to process the required messages in less than about two minutes. Compare that to the amount of time that the MTAs (all 1,000,000 of them – since they all need to do this regardless of the state of their tickets) are likely to take to register, download their configuration files and go through the other parts of the provisioning process, and we think that you will agree that the KDC is unlikely to be the bottleneck.

Q You mentioned that I should run at least two KDCs. Why?

A. There are two ways to ensure high availability: run on expensive hardware that includes redundancy, or run multiple pieces of inexpensive hardware. Since the basic hardware requirements of the KDC are relatively modest (see the example above) there is little point in using expensive hardware. MSOs are rightly concerned about capital expenditure. By deploying two tightly-coupled KDCs running on PC-class rack-mounted hardware, they can obtain high availability at very little expense. Not that we will stop an MSO from running a KDC on a high-availability $20,000 Solaris box if he really wants to. After all, the customer is always right. Right?

Q What does “tightly-coupled KDCs” mean?

A. It means two or more KDCs that serve the same Kerberos realm and share a common database. The IPfonix, Inc. KDCs support this (we call it “peering”). A one-line entry in the configuration file turns on peering. Once turned on, the group of peers, which may number as many as ten KDCs, transparently maintain synchronised databases. Individual peered KDCs can be taken down for maintenance or upgrade and returned to the peer group without interruption of service to the subscribers.

Q. How long does a KDC take to boot?

A. It’s so short that we can barely measure it. From pressing “enter” to the time that the KDC enters service is typically approximately one second. The exception is that if the KDC is part of a peer group then it may take several seconds for the KDC to boot, since it must communicate with its peers and determine a common state before it comes into service. However, the unit to bear in mind here is “seconds” not “tens of seconds” or “minutes”.

Q. Can your KDCs be exported from the US?

A. Yes. We have applied for and received a license exception. The only countries to which the KDC cannot be exported currently are: Afghanistan (Taliban controlled portions), Cuba, Iran, Iraq, Libya, North Korea, Sudan, and Syria.

Q. The PacketCable specification requires support only for pre-provisioned service keys. But managing such keys can be a real headache for an MSO. What about dynamic service keys?

A. We are glad you asked. Managing pre-provisioned keys can be more than a headache, it can be a real nightmare. The only thing worse than managing pre-provisioned keys is not to bother managing them, by the simple expedient of provisioning them once and then never bothering to change them. So we believe that it is imperative that devices support dynamic keys. Since the PacketCable specification does not yet mandate any particular mechanism for this, we have instituted one of our own, based as closely as possible on the PKINIT profile in the PacketCable specification. The details of our interface for service key versioning is available in the User Guide. If you have questions, we would be happy to discuss this interface and the security decisions that drove its design.

Q What about CableHome? Most of this has been about PacketCable.

A. The CableHome requirements on a KDC are substantially less than the PacketCable requirements. Most of the questions we receive concern PacketCable, perhaps because PacketCable development seems to be considerably more advanced than CableHome development (at least for now), and also perhaps because CableHome is much less complex (symmetric key AS-REQ/REP, PKCROSS and MTA FQDN interfaces are all absent from CableHome). If you have specific CableHome questions, we would be happy to address them.