Jeffrey Hutzelman wrote:
>
> 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.
True, but the point was to use K5 authentication, and AFS could continue to do
what ever it wants for its protocol. The point you make are improvments to
the protocol, which could occur at a later time.
>
> 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.
>
The above are also improvments to the AFS protocol, which don't need
to be made to get the authenticaiton to use K5. It will still limit
it to a 56 bit DES key.
> 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.
Yes, that me! Its called ak5log.
> 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.
And that is what we do.
>
> > 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).
>
The way I heard it, AFS is now in Austin, and IBM appears to be doing a lot
of K5/DCE work from there. So there should be some good people available.
Users need to bug them to get this moving.
> -- Jeff
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
