Microsoft Referral Code for Clients
hartmans at MIT.EDU
Wed Jul 9 19:33:24 EDT 2003
>>>>> "Wachdorf," == Wachdorf, Daniel R <drwachd at sandia.gov> writes:
Wachdorf,> I am looking into implementing the MS referral code
Wachdorf,> for clients. The server side referral code already
Wachdorf,> exists in a patch available from the University of
Wachdorf,> Michigan. The client code would allow clients to be
Wachdorf,> ignorant of all trust relationships. The
Correcting the terminology. A shared key between two Kerberos realms
does not imply trust between those two realms. A shared key between
two Microsoft domains does imply trust, but that is a Microsoftism,
not a feature of Kerberos. There's nothing wrong with that, but
assuming that Kerberos shared keys either do or should imply trust is
Wachdorf,> The problem I have realized is that the principal
Wachdorf,> in_cred->service will be service_principal at localrealm
Wachdorf,> and the principal
out_cred-> service will be service_principal at foreignrealm. Does
Wachdorf,> matter? GSSAPI doesn't seem to care. Do developers
Wachdorf,> who use the native Kerberos code usually make sure that
Wachdorf,> in_cred->server matches
out_cred-> server ?
This is probably fine and is a necessary change before supporting this
MIT is unlikely to accept such a patch unless at least the following
conditions are met:
1) The client prefers its own idea of domain to realm mapping to the
KDC's except when the client does not have configuration
information for some realm.
2) Cross-realm referal tickets issued by a KDC other than the local
KDC are not cached. There are some cache poisoning attacks if the
cross-realm ticket does not represent the shortest path. See the
Kerberos clarifications draft for a discussion of these issues.
Not caching the tickets may be unacceptable from a performance
standpoint. If that's true then your patch would need to make
sure that tickets were cached but only if they were along a
4) In cases where the client is deciding what foreign realm to .
the code should support KDCs returning "closer" tickets per RFC
1510 and clarifications. Careful thought is required to decide at
what points the KDC can change the realm of the ultimate server to
make sure that client configuration wins when it is present.
5) Loops must be avoided.
6) I'm not sure we would accept client side patches without
server-side patches. Umich has not submitted their server-side
patches for inclusion and we know of no plans on their part to do
7) As usual patches are accepted against the current development
version, not against released versions.
I don't know that we would accept a patch meeting these constraints.
I know that we do eventually want the feature. There may be other
concerns that other members of the Kerberos team have. If you are
interested in writing patches to be accepted, let us know and we can
check internally to see if there are other issues.
More information about the krbdev