Subject: Understanding Section 5 decision

From: Sam Hartman <[email-masked]>
Date: 17 May 2001 22:12:04 -0400

At the lunch meeting on section 5, we took a rather drastic, and I
think for many of us unexpected step.  We forked the primary document
of this working group  into two directions.  As Doug described, the
5.1 document  that addresses interoperability problems and currently
implemented features.  The 5.2 document would be the new features and
cleanups that cannot go in the 5.1 document.

I think we need to discuss this consensus and validate it on the
working group list.  I would hate to reach London and find that while
the consensus we reached was acceptable to the group of 12, it was not
acceptable to the working group as a whole.  I think this consensus
will likely be validated here; we had a significant cross-section of
implementers at that meeting and no one raised objections to Doug's
summary.  

So, first I'd like to review my impression of why we came to this
decision.  I'm sure I'll get some things wrong, but that's to be
expected; I'm simply trying to present my impressions of the
concerns people may have.  Then I'd like to discuss the potential
down sides of our decision and what I think we should watch out for as
we move forward.

Apparently at the meeting, people were concerned about Tom's additions
to section 5.  Tom added several new message types to fix some
long-standing problems with the ASN.1 in the draft.  Before Tom's
changes, there were significant incompatibilities between RFC 1510 and
revisions-7.  We weren't sure exactly what would break; it would
depend on implementation details of the ASN.1 tools used.  However,
MIT has had significant experience over the years with hard-to-fix
interoperability problems caused by incorrect ASN.1.  Rather than try
and use incorrect ASN.1 and hope that we managed to find out how the
implementations of Kerberos we knew about would deal with the ways we
abused ASN.1, Tom decided to correct our usage of ASN.1.  He tried to
minimize the changes to the protocol while guaranteeing that correctly
implemented ASN.1 tools could work with the spec.

Others were concerned about the new message types introduced.  They
believe that the testing and implementation complexity of the system
was significantly increased by adding new message types.  Many of
those expressing concerns didn't understand ASN.1 that well and thus
they were not convinced that the direct Tom took was the correct
long-term direction.  Also, I believe that there was concern that
discussion of details of the new messages might drag on for a long
time.  So, we decided to split the document as Doug described.

This document could serve several useful purposes.  First, it will
document something closer to RFC1510 and to what currently is being
used today than either the the previous draft of revisions or the
current draft with Tom's changes.  Also, if the discussions over
details of the 5.2 section 5 do drag on, then we may save time getting
some standard produced with the 5.1 document.  

The 5.1 document may be simpler to implement than 5.2 or the current
draft.  New messages are not introduced, so encoders to encode and
decode these messages are not needed.  However, adding new ASN.1
sequences ought to be fairly easy.  The real problem is testing the
new code.  I'm not convinced that testing 5.1 will be easier than
testing the current draft; it may even be harder.  Rather than having
a consistent  policy about how new fields and extensions are
introduced as in the current draft, 5.1 will use whatever tricks we
can come up with to integrate the extensions we want into the existing
ASN.1.  There is no guarantee that we will be able to use consistent
strategies.  Also, some discussions suggested that we might allow some
of the features to be implemented separately, using different flags to
indicate which features are supported.  This increases the number of
combinations that need to be tested.  So, if we want to actually
achieve implementation simplicity we need to be very conservative in
what changes we accept.

While we go forward and develop the 5.1 and the 5.2 documents, we
should be aware of some potential pitfalls.  The first is being
careful about what we allow into 5.1.  Every feature that we allow
into the 5.1 draft will make our lives harder in the future, by
imposing more abuses of ASN.1 that we will have to make sure we can
maintain compatibility with in the 5.2 draft.

We also need to make sure that the 5.2 draft does happen and that it
is implemented.  I'm concerned that many may view the 5.1 spec as
"good enough," and not have significant interest in working on the 5.2
spec.  However, if this happens, these vendors will later have
features that they want to support that are not part of 5.1.  Alone
none of these features will be a significant enough change to really
justify adding message types and developing a 5.2 spec.  There may be
significant pressure to continue revising 5.1 one hack at a time .
One of these small features that we add in the future may prevent
evolution beyond that point. We have narrowly avoided such problems in
the past: we came very close to being unable to
expand the kdc-req because of the ASN.1 problems, but were saved by
preauth data.

Even if work progresses on 5.2, there is the danger that we will get
bogged down deciding what should be added to 5.2.  Discussion could
easily drag on and prevent 5.2 from  being deployed in reasonable
time.  We would need to have a clear idea what goals we had for 5.2.

However if we are two successful trimming the scope of 5.2 then we may
 find ourselves in a situation where there is not enough in 5.2 to
 interest vendors, and they choose not to move from 5.1 to 5.2.  This
 puts us back in the position of trying to continually extend 5.1.

--Sam