From: [EMAIL PROTECTED]
Wasn't it actually Stanford that wrote the "aklog" and "asetkey"
programs? I could be wrong since I wasn't working with AFS at the
time these solutions were first introduced. If the author would
kindly step forward, I'd love to know who to give the credit to!
Well, actually, MIT wrote it, and gave it to Stanford. The versions
that are in grand.central.org also come from MIT. Paul Traina, formerly
at Stanford, made a document describing how to put it altogether for
other customers (especially since we had not documented it). To be more
specific, the authors (in order) of aklog are: Bill Sommerfeld/MIT, Jay
Berkenbilt/MIT, and Richard Basch/MIT. The authors (in order) of
asetkey are: Bill Sommerfeld and Richard Basch. The document that is
given to customers by Transarc was written by Paul Traina/Stanford. The
company tags associated with the people listed are those at the time the
work was done (Bill now works for HP, Jay now works for ERA, and Paul
now works for Cisco).
At the AFS User Group meeting in January, I had the opportunity to
talk to a lot of people about the interoperability issue. I
understood that Richard Basch of MIT is indeed running Kerberos V5,
but that he has the V4 compatibility options enabled. I got the
distinct impression that he is still using the same solution that he
used for V4. Richard, would you care to comment?
Further discussion was raised about the OSF DCE security module, since
Kerberos V4 support is *not* currently included in that offering.
Gregg Lebovitz of the OSF confirmed that this is the case. Perhaps
this is related to the solution that Geer Zolot Associates is
offering?
Currently, I do not know of any AFS interoperability with Kerberos V5.
I have found out a lot more about V4 and V5 interoperability. In V5,
the server passes back a "salt type" and "salt data" fields, and one of
the "salt types" is a token indicating that the V4 string-to-key
function should be used. Therefore, it is theoretically possible to
keep your existing V4 key database when moving to Kerberos V5. However,
I do not believe there is any salt-type to indicate the "kaserver"
flavor of the string-to-key function.
Assuming the OSF/DCE has not completely taken out the V4 string-to-key
option that was part of the V5 spec, there may still be a chance of some
interoperability. The support for handling V4-style ticket requests may
require additional compilation options and may not be enabled, but did
they also disable the additional salt-type/salt-data functionality
provided in the V5 spec? I think only OSF can answer that one...
Perhaps when ISODE is ripped out of Kerberos V5 and replaced with a much
simpler ASN.1 parser, I will attempt to integrate that into AFS. It
shouldn't be too difficult since a token is simply an opaque structure
anyway. On the server, I can attempt to decrypt the token and if it is
a valid ASN.1 format, simply do some simple mapping of the identity into
a ptserver-style format. If it isn't ASN.1, then it is obviously a V4
style ticket. Also, it may be possible to tell the style by looking at
the beginning of the decrypted data and seeing if the beginning is a
valid checksum for the rest of the data. I believe a checksum now
appears at the beginning of the "token" to make it even more
unpredictable. I suspect that most of the changes will have to be done
in the name-mapping and the decomp_ticket routines in AFS.
-Richard
