[2017] in Kerberos-V5-bugs
Re: Kerberos 5 beta 6 and AFS tokens
daemon@ATHENA.MIT.EDU (Doug Engert)
Tue Jun 18 11:50:23 1996
Date: Tue, 18 Jun 1996 10:49:56 -0500
From: Doug Engert <DEEngert@anl.gov>
To: Marc Horowitz <marc@MIT.EDU>
Cc: Doug Engert <DEEngert@anl.gov>, krb5-bugs@MIT.EDU
In-Reply-To: <9606172230.AA19252@beeblebrox.MIT.EDU>
Marc,
Thanks for your comments on the krb524 suggestions. I would like to
address them.
Marc Horowitz writes:
> 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.
>
As I pointed out this was a suggestion, and the code had the AFS524
define to control its inclusion. Even if it is defined, if the
/krb5/afs.afscellname file(s) are not present, then the code also does
nothing.
> 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.
>
I don't want to treat the AFS cell as a full blown K4 cell, but
rather as an application which needs tickets from some other Kerberos
realm. AFS and the "r" commands are our big "K4" applications. K5
addresses the "r" commands, we need to address the AFS issues.
The intent is to eventually get rid of the AFS kaserver, and have all
users registered in the K5 realm. This then in effect places the AFS
cell under the K5 realm, but it may have a different name. This is
exactly the way aklog uses the -c and -k options to specify which
Kerberos realm (-k) can give out tickets for which AFS cell (-c). The
modified aklog uses these as well with the -c being the AFS cell, and
the -k being the K5 realm.
We are using the DCE security server as the KDC and they did not
implement the K4 ticket granting features, so we are forced to do as
much as possible using the K5 capabilities. including using the
DCE/K5 intra-cell capabilities which work with DFS, and to apply these
to the AFS.
> 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,
Yes I could have, but the conversion being done here is different for
the ones down in the krb5_524_conv_principal. There is the additional
check that the client is in the same K5 realm as the K5 ticket to be
converted, and both the client and server names are changed at the
same time. So it looked much more straight forward to put the code in
the krb524 routine inside the #ifdef.
> 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.
>
That was the first cut at this code last year. But trying to keep the
keys in sync between the K5 (DCE security registry), the AFS kaserver
and the AFS /usr/afs/KeyFile was a nightmare. The procedures were not
straight forward, the people who maintain AFS did not understand it,
and we took down a production AFS cell trying to implement this. The
new approach of having the a separate K5 principal and key for
afsx/... and using the AFS KeyFile greatly simplified the management
process. (i.e. copy the /usr/afs/etc/KeyFile from the AFS server to
the KDC's /krb5/afs.afscellname) The added complications to the
krb524d code is worth it.
> 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.
I have no problems resubmitting the changes using the krb5.conf file
options. This in effect would replace the "#ifdef AFS524" with a if
(profile(....)) construct. The only AFS dependency in the code
currently is a #include </usr/afsws/include/afs/keys.h> in
cnv_tkt_skey.c. How about something like: [krb524] convert_afsx = 1
If this sounds reasonable, let me know, and I will make the changes.
If you are interested the changes to the aklog program to use the K5
protocals, and the changes to krb524d can be found at:
ftp://achilles.ctd.anl.gov/pub/kerberos.v5. The aklog.tar.Z is the
original tar file of aklog, aklog.cdiff.960618 has the changes
and k56.cdiff.960612 has all of my changes to K56 including the krb524
changes.
Thanks.
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(708) 252-5444
PGP Key fingerprint = 20 2B 0C 78 43 8A 9C A6 29 F7 A3 6D 5E 30 A6 7F
