[613] in Kerberos-V5-bugs
More on Shortcuts
daemon@ATHENA.MIT.EDU (Clifford Neuman)
Tue Aug 2 10:10:09 1994
Date: Tue, 2 Aug 1994 07:10:08 -0700
From: Clifford Neuman <bcn@ISI.EDU>
To: DEEngert@anl.gov
Cc: krb5-bugs@MIT.EDU, auth-pilot@es.net
In-Reply-To: "Doug Engert"'s message of Tue, 02 Aug 94 08:53:07 CDT <199408021353.AA23501@venera.isi.edu>
Date: Tue, 02 Aug 94 08:53:07 CDT
From: "Doug Engert" <DEEngert@anl.gov>
I am running the krb5.src.B4-1.tar.Z and krb5.crypto.B4-1.tar.Z
with isode.tar.Z from k5.3 for some archs built with Imake.
Can you point me at some code which I can look at to
verify if I have the CyberSAFE mods?
Look at the top of lib/krb5/krb/gc_frm_kdc.c for a CyberSAFE
copyright notice.
You said "it will return the ream closest to the target for which
it does share a key." How do you define closest? Does it depend
on the realm names, and check all the realms returned by the
walk_rtree routine to see if it has a key?
Yes.
But the code I submitted does more. It alters the list returned
by walk_rtree, and insert and/or deletes realms. As such it may work
with the CyberSAFE code, if the CyberSAFE uses the walk_rtree
list.
Yes, the CyberSafe code does use the walk_rtree list. There are still
some issues related to false starts that may cause it to miss certain
shortcuts. In particular, if B.C.D shares a key with X.Y.Z, and C.D
shares a key with T.U.V.W.X.Y.Z, and one tries to authenticate from
A.B.C.D to T.U.V.W.X.Y.Z, then it will find the shortcut from B.C.D to
X.Y.Z and walk down the tree from there, never finding the shortcut
from C.D that it would have found if it only popped up one higher.
The ESNet Authentication Pilot Project is trying to use cross
realm authentication by having a ESNet realm which will share
keys with the rest of the member organizations. i.e. 2N rather
then N(N-1) keys. These organizations don't want to have their
realm names depend on the name of the ESNet realm. Therefore just
walking the realm names will not work. on the
o ANL.GOV, FNAL.GOV, LLNL.GOV, PNL.GOV, and NERSC.GOV all are
members on ES.NET and want to cross authenticate using the
ES.NET realm.
o But ANL.GOV, and FNAL.GOV are also members of HEP.NET, and
would rather cross authenticate using HEP.NET rather then
ES.NET. (An example, ANL and FNAL have not discussed this.)
You are correct, it would not handle the above situation because the
path is determined by the names of the realms. I think that it would
be worthwhile to include your changes to support this. I would prefer
that it not be called shortcut, since that implies (not from the
dictionary meaning, but the way I use it) bypassing parts of the
hierarchy. Instead I would call it something like
CONFIGURABLE_AUTHENTICATION_PATH.
How is it that you validate the authentication path on the server
side. In particular, if you stay within the hierarchy defined by
the old walk_rtree, only skipping hops, it is easy to define a policy
that says what is allowed in the transited field. Once you allow
other realms to be involved, you need to guard against realms that
shouldn't be involved appearing in that path. That is a policy
decision on the application-server side.
~ Cliff
