On 06/06/00 15:43:45 -0500 "Douglas E. Engert" <[EMAIL PROTECTED]> wrote:
>> Unfortunately, it's not that simple. The DFS migration toolkit required
>> a number of special tools, including a translation server. The cache
>> manager knows nothing about krb5; it believes it is talking to a normal
>> AFS server using normal V4-based rxkad.
>>
>
> Yes I realize it is not that simple. What I was pointing out was that
> cache manager and the protocols appear not to need modifications, just
> the servers. And that Transarc as already done some of the work when they
> wrote the translator.
Except that the cache manager needs to know and be able to use the session
key in order to make an authenticated connection. That means you're
essentially restricted to using 56-bit DES keys in the way that rxkad
already does. You could do something, but it wouldn't be krb5.
There are no authentication-related changes in the cache manager to support
the DFS translator. All the work is done in dlog and in the translator
itself. As with klog, the cache manager is handed an encrypted blob to
hand to the remote end, a kvno, and a 56-bit DES session key.
You could build something that uses this fact to hand the cache manager a
V5 ticket, like dlog does, but the protocol wouldn't be V5-based, and you'd
still be restricted to rxkad's existing authentication mechanism using
56-bit DES and fcrypt for data stream encryption. That means it wouldn't
work with V5 tickets that didn't happen to include a DES-CBC-CRC key.
You also wouldn't be able to have cells with a mixture of new and old
fileservers -- you can't use the new clients at all until all of your
fileservers have been migrated.
At that point, you may as well run krb524d on your KDC or AFS database
servers, and use krb524init and the V4 aklog (in fact, I believe someone
has released a V5-aware aklog that rolls the krb524 operation into the same
binary. You still have to be running a krb524 service, of course, since
one needs the service key in order to do the translation). This is a
solution that will work _today_ for people who want to use a DCE or Win2K
KDC with their AFS cell.
> One of the questions is: Should AFS be treated as a service, in a realm,
> running under principals such as: afs/<afscell>@<k5-relam>
>
> This could allow multiple AFS cells to be served by a single realm, or
> even multiple realms could issue tickets for the same cell.
There is precedent for this -- there are several cells at MIT which all use
the ATHENA.MIT.EDU realm, using service keys named
afs.<cellname>@ATHENA.MIT.EDU.
I think the correct behaviour is pretty obvious -- first try
afs/cellname@REALM, and then just afs@REALM; in both cases, REALM is the
realm containing the cell according to domain_realm mappings. (the current
MIT aklog actually uses the realm containing the cell's database servers; a
subtle but potentially important distinction). The resulting ticket can be
used as-is with mythical V5-aware rxkad, or handed to the krb524 translator
to get a V4 ticket that can be used with the currentlty-available AFS
software.
> I would like to see Transarc go forward with this project, which would
> allow one to use what ever Kerberos KDCs they wish with AFS servers.
Yeah, so would I. But I sincerely doubt that there is anyone left there
with both the understanding and motivation needed to do it right. As far
as I know, all of those people have left (no offense intended if some such
people are still at Transarc -- I just don't know of any).
-- Jeff
