[2013] in Kerberos-V5-bugs
Re: Kerberos 5 beta 6 and AFS tokens
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Mon Jun 17 18:31:34 1996
To: Doug Engert <DEEngert@anl.gov>
Cc: krb5-bugs@MIT.EDU
Date: Mon, 17 Jun 1996 18:30:42 EDT
From: Marc Horowitz <marc@MIT.EDU>
It is my opinion that your changes are too afs-specific to be
desirable to include in the MIT krb5 release. However, it is also
clear that any other implementation of your functionality would
involve a great amount of code reuse.
It is clear (to someone who understand kerberos, at least) that
host/foo.anl.gov@ANL.GOV and rcmd.foo@ANL.GOV refer to the same
entity, and that any conversion in form between v5 and v4 requires a
conversion of the contained names as well.
AFS is different, because you are, as you point out, creating an
equivalence in naming between two domains (the cell names and the
kerberos realm names) which is not inherent. What you are really
asking for here is a mechanism to rename a kerberos ticket somewhat
arbitrarily. The Transarc answer to this in AFS (I don't know about
DFS) is to use intercell naming (the system:authuser@other-cell hack
in the pts database) and to explicitly give permission to the
other-cell users when they need it. So, in your environment, I
believe you should use would use krb524d as to convert from the
anl.gov and dce.anl.gov DCE ticket space to equivalent v4 ticket
spaces, and then use the AFS mechanism provided by transarc to use
your dce.anl.gov v4 tickets in the anl.gov afs cell.
All that said, if you still see a need to be able to do all these
conversions, there is already a conversion facility in krb5. You
could add code to krb5_524_conv_principal to do the afsx/cell@REALM
name mangling, and store the afs key (from the KeyFile) in the same
keytab as the afsx key. This requires less code, none of it
afs-specific. I still wouldn't want to see this code present in the
MIT release, but it would be an easier delta for you to maintain.
Alternately, you could make the conversion routines dependent on a
stanza in the krb5.conf file, with semantics general enough to support
your conversion needs. This I wouldn't mind including in the MIT
release, since the part I think doesn't belong would be a matter of
your local site customization at that point.
Marc
