[6186] in Kerberos
Re: How to make V5 and V4 work together
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Wed Nov 8 18:45:47 1995
Date: Wed, 8 Nov 1995 18:27:51 -0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: jec@isoft.com
Cc: "Theodore Ts'o" <tytso@MIT.EDU>, milman@austin.ibm.com, kerberos@MIT.EDU,
jiewang@lieland.stanford.edu, Mark_Sherman@transarc.com
In-Reply-To: Jonathan Chinitz's message of Wed, 8 Nov 1995 18:07:05 -0400,
<v02120d06acc6d83761d9@[199.33.247.8]>
Date: Wed, 8 Nov 1995 18:07:05 -0400
From: jec@isoft.com (Jonathan Chinitz)
Correct me if I'm wrong but I was under the impression that due to
different string-to-key functions that the kaserver and Kerberos KDC could
not share keys either, no? If this is true then it is not just DCE that is
causing you a problem here.
The KDC can store keys marked with different salts, and different
string-to-key algorithms, for backwards compatibility with the kaserver.
(Sites using AFS with the MIT Kerberos V4 don't have this problem; they
just win automatically.) The trick is that you store the key from the
kaserver database, and mark it with a salt-type meaning that it's using
the AFS3 string-to-key algorithm.
Legacy AFS clients using klog can now win, since the database has the
right key in it. In order for K5 kinit-type program to be able to know
to use the correct (AFS3) string-to-key algorithm, the following
preauthentication type has been reserved for the purpose of indicating
that an AFS salt is in use:
#define KRB5_PADATA_AFS3_SALT 10 /* Cygnus */
If a KDC_AS_REP message contains the following preauthentication
message, it's a hint to kinit that the AFS3 string-to-key algorithm was
used.
Changes to do this aren't in the Beta 5 distribution, but the changes
needed to support this aren't hard.
In any event, if you do have a common KDC that is V5 based for your K
clients and AFS clients then the DCE security server can serve that
function just as well. Furthermore, the DCE security API does support the
ability to insert a DES key, assuming you have the right salt.
No, a DCE security server can't serve this function, because a DCE
security server won't issue V4 tickets, and you need V4 Kerberos tickets
for AFS tokens (and other legacy K4 applications). That is the crux of
the problem. Being able to insert a DES key directly into the database
doesn't help if you can't get the DCE security server to generate V4
tickets.
However, assuming that DCE's dcelogin supports the above mentioned
preauthentication type, and its database could support a new salttype
meaning that the AFS3 string-to-key algorithm was in use, it would be
possible for DCE to support a transparent migration for a site which is
using a kaserver.
- Ted
