Subject: Re: Understanding Section 5 decision

From: Ken Raeburn <[email-masked]>
Date: 22 Jun 2001 17:25:50 -0400

Sam Hartman <[email-masked]> writes:
> 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.

Given that section 9.1 of RFC 1510 describes that document as
"Kerberos Version 5 Specification 1 (5.1)", I suggest we renumber
these new versions *right now* as 5.2 and 5.3, to avoid confusion.

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

Well, I'll note two things.
1) I don't think I've heard either positive or negative comments on
   the idea at all, from anyone outside our Gang of Twelve.
2) The same was true regarding Tom's changes to section 5 before the
   last WG meeting.  Cliff had heard some complaints, but I don't know
   when, and I (and Tom, I believe) had heard nothing of them an hour
   before the WG meeting.

So clearly the lack of objections is not to be taken as general
approval.

IMHO, whoever was grumbling about section 5 before wasn't doing so to
the right audience, or at the right time.  We have a lot more time for
discussion and thought using the mailing list than during a WG
meeting.

I realize a more concrete proposal for the next revision (the one we
had called 5.1, and I want to call 5.2) would be easier to discuss,
but the general notion of the split has been described a couple of
times, without much feedback.

Okay, well, here's my opinion:

Clearly, the first revision should fix the places where RFC 1510
doesn't agree with reality.  Bitfield definitions, preauth types used
but not defined, *something* about the GeneralString problem, etc.
What else should it include?  IMHO, very little, and all as
backwards-compatible as possible.  Maybe a workaround for
KRB-SAFE/PRIV requiring the sender address -- the workaround probably
taking the form of a dummy address, and a recommendation that it be
used only if the address is unavailable since RFC 1510 implementations
wouldn't look for the magic address.  (I.e., behave differently only
in a case where it couldn't have been used at all, much less
successfully; maybe it'll still lose, but it'll have half a chance.)
Maybe add size bounds for arrays.  Nothing that'll require a new "I
support RFC1510bis" flag.  No new optional fields -- we've got quite a
few in the works, and they're probably going to be the driving reasons
behind the following revision; let's get the extensibility right,
*once*, when we do it at all, even though it means bigger changes to
messages.  Like Sam said, let's not jam stuff in haphazard fashion
into the first revision to make it "good enough" so that we never get
around to fixing things more cleanly.

Of course, this probably also implies backing out some changes to
section 3 as well.

There's also the question of which features, present in some
implementations but not in others, to include.

Ken