Requesting use of addresses in forwardable tickets

Ken Raeburn raeburn at MIT.EDU
Wed Sep 11 01:57:01 EDT 2002

Cesar Garcia <Cesar.Garcia at> writes:
> 1 - make it possible is issue forwarded tickets that do not include IP
> addresses.

If the ticket you've got doesn't have an IP address either, you could
just forward it to the remote system.  If you don't mind having that
side re-use the same session key etc.

> CyberSafe (sigh) solved this problem by having the target host compare
> IP addresses in the forwarded tickets with it's local interfaces. If
> there was a mismatch, it would use TGS to acquire a new ticket that
> included a full set of tickets. Presumably, the socket used for this
> request was bound, as in bind(), to one of addresses available in the
> originally forwarded ticket. I believe they did this only if there was
> at one or more addresses in the forwarded ticket, so as to allow for
> meeting requirement 1. Perhaps this approach is worth considering.

That's certainly the approach I'd suggest.  The current MIT krb5 code
doesn't bind a specific local address when talking to the KDC, but
that could be changed.  If the default address for contacting a KDC is
reasonable, though, it should probably be used, for presumably better
routing, rather than picking one of the local addresses at random.

Say, open a socket, connect, look at the local address, if it's an
unlisted one, drop the connection, then bind a socket before
connecting.  Or maybe only bother with the lookup if the KDC says it
doesn't like the address we used, since it's an uncommon case we're
looking at.

To make it more interesting, such an error probably shouldn't cause
the library to back out of the "try to reach multiple KDCs in
parallel" loop, if possible.  One of the other connection attempts in
progress may still work.

Kind of messy.  As if the send-to-kdc code weren't messy enough
already....  I don't expect I'll tackle this any time soon, but I have
been hacking on that code recently and may do some more to try to
clean it up a bit in the near future.  If anyone wants to tackle this
problem, please talk to me about it.


More information about the krbdev mailing list