Subject: [extensibility 1] Why do we need to think about extensibility in Kerberos?

From: Sam Hartman <[email-masked]>
Date: Wed, 5 Dec 2001 00:38:18 -0500 (EST)

While discussing section 5 of the Kerberos revisions document in
London, Tom presented an outline of a strategy to handle extensibility
by using ASN.1 constraints and ASN.1 choices.  We believed that this
strategy would add enough extensibility features to deal with parts of
the protocol that were made optional in revisions, adding ticket
extensions, providing the framework we need for UTF8 and solving
backward compatibility problems while avoiding the unnecessary
complexity and protocol changes that concerned the working group with
the proposal made in Minneapolis.  The working group seemed generally
receptive to this approach and Tom indicated he would move forward.

Since then, Tom Yu, Ken Raeburn, Jeff Hutzelman, Jeffrey Altman and I have been working to flesh out this proposal and
confirm that it met our needs.   

Over the next few days we are presenting our findings to the working
group.  This message presents a more detailed explanation of why  we
need to address extensibility in Kerberos than was presented in
London.  Future messages will explain why we believe that  we need to
think about all the extensibility issues together rather  than
handling each of them separately.  We will then present the details of
our proposal including  exactly how clients can discover if a KDC or
service has  support for new protocol features in a backward
compatible way.  We do have a specific proposal ready, but we want to
make sure that people understand the motivation before presenting
ASN.1.

			  Why Extensibility?

One of the primary arguments for building extensibility into Kerberos
is to meet changing market requirements.  In the past we have seen
that companies cannot wait for the standards process to provide the
features they need.  Companies can choose which existing standards
they use, and how they fit their needs into those standards, but in
general waiting to ship a product on changing a standard creates
unacceptably long delays. If Microsoft had waited on the
standardization of the kdc-issued authorization data element, Windows
2000 would still be delayed.

We certainly want companies to be able to use our standards.  However
we want them to use our standards in such a way that products from one
company will interoperate with products from other companies.  In some
cases we can make our standards general enough or tailored to a
specific need so that products will not have to extend them.  For
example, most
companies implementing IP do not find the need to extend the protocol;
it solves the very general problem of getting packets from one point
to another.  For other IETF standards, we suspect that vendors will
want to extend the standard.  HTTP has been popular in part because
vendors were able to test out extensions like caching, byte-ranges
and vendor-specific additions in a compatible way without waiting for
the standards process.

Parts of Kerberos are like IP.  I can't see that many ways a vendor
would want to extend the krb-priv message; if they want to send
different data they can just  put something different in the user data
field.  Other parts of Kerberos seem more like HTTP: many proposals
have taken advantage of the padata fields in KDC messages, while other 
proposals  have used the authorization data elements.

It seems likely that future Kerberos work will continue to make use of
Kerberos extensibility features. The working group has received
 pressure for some extensibility features in the current
draft.  There was a significant desire to better explain and define
how authorization data worked; that text has been in the draft for
a few years.  Several groups indicate they need ticket extensions,
and while not in the current draft, they have been in past
drafts; it seems unlikely that we will get consensus on a
specification that does not provide ticket extensions.  We also need
extensibility in character set choice (UTF8 support).  So it is
clear that at least some extensibility features will be needed.

In order to evaluate what extensibility mechanisms the Kerberos
protocol needs we need to weigh the costs of adding/keeping these
mechanisms against the costs of not including them.  We cannot predict
the future to know how much it costs to leave a particular feature out
of the protocol but we can  consider similar protocols and look at how
they have evolved over time.  It turns out that Kerberos Version 4
proves enlightening in this regard; in many ways Kerberos 4 is like
Kerberos 5 with all the extensibility options removed.

Despite the lack of extensibility features in the protocol, several
extensions were added to Kerberos 4 by various vendors.  Some vendors
added preauthentication.  Others added support for an exponential
lifetime mechanism to better take advantage of the byte Kerberos 4
allocated for storing ticket lifetime.  Other vendors ignored the IP
address field so they could forward Kerberos tickets.  Some
implementations added support for smart cards.  None of these
extensions were anticipated in the original Kerberos 4 protocol.  From
this we find that vendors can often shape a protocol to meet their
needs even when they go beyond the scope of the original design.

However we learn another important lesson when we look at
interoperability between Kerberos 4 implementations.  Since the
extension mechanisms were not designed into the protocol, little
thought was put into making sure extensions were only used between
peers that both supported the extension.  Significant interoperability
problems existed between some implementations; long lifetime tickets
were notoriously problematic.  Applications that expect to be able to
forward Kerberos 4 tickets do not work in realms where the KDC expects
to be able to check IP addresses.  Realms expecting preauth cannot
easily interoperate with other realms; in addition, if another
implementation were to use the same extensibility mechanism then
significant interoperability problems would be created.  So We do run a
risk that if our extension mechanisms are inadequate, we may find that
implementations cannot interoperate using the extensions, and worse
that implementations cannot negotiate with peers to find out what
capabilities are present.

Since there is a significant cost to providing insufficient
extensibility, we must consider the tradeoff between this cost and the
costs of adding extensibility.  When we add extensibility, it
increases the complexity of our design.  It also increases testing
complexity.  We propose that at a minimum, we need to make sure our
protocol is sufficiently extensible to meet the needs of proposals
under serious discussion.  This should certainly include making sure
that we have enough extensibility features for proposals that have
reached draft form.  As I mentioned earlier, we believe we have
specific ASN.1 that accomplishes this goal.

However vendor extensibility is not the only argument motivating
extensibility features in Kerberos.  We also need to make sure that
the IETF can make backward-compatible changes to the protocol in the
future.  I think many people were shocked when Tom pointed out in
Minneapolis that we cannot ever increment the Kerberos protocol
version number without making it impossible for old versions to
interoperate with new versions.  It turns out that we have been able
to propose solutions for all the changes that we desire to make.
However, as we have evaluated some of these proposals, we have
realized that we need to be careful; some extension options we have
proposed may make it more difficult for us in the future.  So we
should also consider how the Kerberos protocol can evolve when we look
at extensibility and make sure we add enough extensibility features
that we do not box ourselves into a corner.

In conclusion, as discussed in London, we believe that we need to look
at how we handle protocol extensibility for Kerberos.  We want to
balance the needs of vendors trying to get features to market in a
compatible manner against the complexity of protocol extensions.  We
also need to keep in mind the IETF's need to be able to come back to
the protocol in the future and preserve interoperability.

In the next message, I plan to argue that we need to consider all the
extensibility features together.  We cannot proceed as we have in the
past--adding ticket extensions here, removing some fields there.  We
certainly cannot ignore the problem of capability negotiation;
whenever an extension is used, the using party should be able to know
how the extension will be handled by the receiver.