Microsoft Referral Code for Clients

[Sam Hartman]

>>>>> "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
wrong.
    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
    out_cred-> this
    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
functionality.

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
   shortest-transited-path

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
   so.

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.

--Sam