Requesting use of addresses in forwardable tickets
Douglas E. Engert
deengert at anl.gov
Wed Sep 11 09:59:00 EDT 2002
Ken, Did you see my note on this as well?
Some of hte other people I talk to are having real problems in this area,
as NAT and firewalls become more prevasive. They are willing to live without
the addresses in the tickets. There appears to be be two simple solutions,
o On the client side that request a forwardable ticket, don't add addresses.
ifsome parameter is set, like a krb5.conf [libdefaults] no_addresses=1
o On the KDC, if the TGT has no addresses, don't add addresses to the
new TGT. (This needs to be subject to some policy.)
Both of these look like 10 lines of code at the most. I would favor the first,
Will try and have some code later today.
Ken Raeburn wrote:
> Cesar Garcia <Cesar.Garcia at morganstanley.com> 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.
Really don't like this, as there may be other bits or fields being
set in the new TGT. If not today, in the future. Don't get into this
bad habit today.
> > 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.
But what about NAT? Both sides see differnet address when looking at the
> 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.
> krbdev mailing list krbdev at mit.edu
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
More information about the krbdev