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:
- 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.
- 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.