[1057] in Kerberos
Some questions on V5
daemon@ATHENA.MIT.EDU (Jeffrey I. Schiller)
Wed Jul 18 01:45:39 1990
Date: Wed, 18 Jul 90 00:54:00 -0400
From: Jeffrey I. Schiller <jis@MIT.EDU>
To: cmcmanis@ENG.SUN.COM
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Chuck McManis's message of Fri, 13 Jul 90 13:34:46 PDT <9007132034.AA02360@pepper.Eng.Sun.COM>
Date: Fri, 13 Jul 90 13:34:46 PDT
From: cmcmanis@Eng.Sun.COM (Chuck McManis)
There is something weird here and for the life of me I can't figure
out what is really going on. It certainly looks bad, but I'd like to
have the "full story" before I make any conclusions.
I'll try to fill you in on the MIT view of all this. I don't think
anything weird is going on. What you see is the result of an
interesting chain of events.
As you know MIT makes Kerberos available in a "public" sense. We
freely distribute it via FTP with a copyright that allows others to
make use of the technology and the distributed code itself. One of
the implication of this is that others, including vendors can pick up
our work and incorporate it into their products. In general we
encourage this as a "good thing" for it leads to industry acceptance
of what we believe to be good technology.
As part of encouraging wider acceptance and use of Kerberos, we at MIT
encouraged discussion, a lot of it via this mailing list, on how to
improve kerberos. The currently distributed version, version 4, was
designed and implemented to solve the specific authentication problems
that needed addressing for Project Athena. As such it does not support
desirable features that were not in the original problem space of
Project Athena (for example non-IP networking technology or
complicated namely strategies).
The result of this discussion process was the design of V5 kerberos.
V5 eliminates many of the protocol obstacles inherent in V4 and
provides notable enhancements (proxy tickets and renewable tickets
just to name two).
As I am sure you are also aware OSF has a technology solicitation
process. HP/Apollo responded to this solicitation with a technology
that was based on Kerberos with proprietary extensions (which is OK in
that V5 was designed to allow such extensions). This is also a
legitimate thing to do given the way that we have copyrighted
kerberos. MIT did not play a direct role in the proposal from
HP/Apollo to OSF. We did encourage all concerned to submit V5 based
technology rather then V4 technology which we would like to make
obsolete in the not so distant future. HP/Apollo was happy to do this
and OSF was happy to accept this from what I can see.
That is where we stand today vis a vis the OSF DCE offering. Obviously
there is some confusion as to who provides the "reference" kerberos.
Is it MIT or OSF. This is an interesting issue. To help clarify this
and reduce confusion (sometimes our own confusion!) we have been
having conversations with OSF. These discussions are currently ongoing
and at a point where it is hard to say what the future holds.
However there are some things that we can state pretty clearly. It is
not MIT's intent to make Kerberos (any version) proprietary
technology. When it is ready, MIT will make V5 kerberos available in
the same fashion as we make V4 available today.
So Where is V5 you ask?
Behind schedule is the answer.
To date we have had very limited resources for the development of
kerberos (after V4 was finished). The primary developers at MIT are
pretty busy people who all have other responsibilities that have
precluded an intensive effort to get V5 ready. John Kohl, a DEC
employee assigned to Project Athena, has been doing a yeoman's job of
working on V5, more or less on his own.
Where's the final spec you ask... Well that's my fault. I volunteered
to make the last major round of changes to the V5DRAFT RFC (version 2)
which is more or less a rework to remove the bit level packet formats
and convert them to an ASN.1 specification (which is what John is
implementing). I have been busy with other things and haven't had time
to work on it.
Now the good news. We will soon be putting more manpower and internal
priority on V5 kerberos. Although I cannot commit to dates at this
point, I am confident that the rate of progress on getting the code in
alpha-test shape will increase.
Let me address your questions one at a time.
Where is the core part of this V5 Kerberos? (The V5 protocol engine)
Being worked on. I think the text of my message makes this clear(er).
Will V5 be OSF proprietary or will there be continue to be an MIT
open version?
As I stated above, MIT intends for V5 to be as available as V4 from
MIT.
Why can't we get any information on version 5? (Even the final
specification.)
I consider myself poked!
Where is the V5 alpha so that people can make sure they aren't
depending on V4 features that may vanish?
I don't know of any V4 features that will vanish... but your point is
taken. The short answer is: We're working on it.
If Kerberos didn't make the 1 June deadline for OSF does that
mean it is out of DCE?
I don't know. I cannot speak for OSF, nor in fact do I know.
Mumblings :
From the outside looking in, the appearance of a conspiracy to keep
Kerberos out of the hands of people who might ship it before OSF is
evident. I don't think anyone is that silly so I discourage such
rumors whenever I hear them. What I would like is that the people
who keep talking about V5 in the present tense would let someone
else see it. How about a "final" spec even?
I hope I have clarified things for you (and others). From what I can
see from MIT, there are no conspiracies hiding, just some honest
people working hard.
Confused in Mountain View,
Overworked in Cambridge (note the time on this message header, I've
been at work since 8:30AM).
I hope this diatribe helps. If you have any questions feel free to
ask, either via e-mail (to me and cc'd to the list if you like) or via
telephone at (617) 253-8400 (please don't everyone call at once!).
-Jeff
