Requesting use of addresses in forwardable tickets

[Cesar Garcia]

I would favor this solution, as long as applications can override any
defaults defined in krb5.conf (this may be the case, just not familiar
enough with this aspect of MIT kerberos yet).

The bind that I am in is that one of the few remnants left from our
CyberSafe deployment is krshd/krlogind which we run on Solaris. On
linux, we are using MIT kshd/klogind, which results in a neutered set
of tickets. This is not a big problem on linux, as we have yet to
deploy many multi-homed linux machines in our production environment.
But with VCS coming for linux, that's going to change.

The problem is that the cybersafe krshd/krlogind does not handle
request from clients that have NULL addresses, so eliminating IP
addresses day one will break rsh to CyberSafe krshd on Solaris.

We can't upgrade 8000 solaris machines to MIT kshd overnight, so we
need an interim solution that would allow us to, at a reasonable pace,
migrate solaris to MIT kshd. That interim solution may involve
deploying a version of kshd that can do IP address expansion when
receiving forwarded tickets with a neutered set of addresses. As
we remove IP addresses from tickets (if we find we have a need to),
we can.

(Incidentally, because of this dilema, we got around the firewall/NAT
problem by disabling IP address checks on the target side, although in
our case, we only had to modify one application - ssh, as it is the
only kerberized application that crosses perimeters.

>>>>> "Douglas" == Douglas E Engert <deengert at anl.gov> writes:

Douglas> Ken, Did you see my note on this as well? 

Douglas> Some of hte other people I talk to are having real problems in this area,
Douglas> as NAT and firewalls become more prevasive. They are willing to live without
Douglas> the addresses in the tickets. There appears to be be two simple solutions,

Douglas>  o On the client side that request a forwardable ticket, don't add addresses.
Douglas>    ifsome parameter is set, like a krb5.conf  [libdefaults] no_addresses=1
    
Douglas>  o On the KDC, if the TGT has no addresses, don't add addresses to the 
Douglas>    new TGT. (This needs to be subject to some policy.) 

Douglas> Both of these look like 10 lines of code at the most. I would favor the first,
Douglas> Will try and have some code later today.  

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

Douglas> Really don't like this, as there may be other bits or fields being
Douglas> set in the new TGT. If not today, in the future. Don't get into this
Douglas> 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.
>> 

Douglas> But what about NAT? Both sides see differnet address when looking at the 
Douglas> same connection.
 

>> 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.
>> 
>> Ken
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/krbdev

Douglas> -- 

Douglas>  Douglas E. Engert  <DEEngert at anl.gov>
Douglas>  Argonne National Laboratory
Douglas>  9700 South Cass Avenue
Douglas>  Argonne, Illinois  60439 
Douglas>  (630) 252-5444
Douglas> _______________________________________________
Douglas> krbdev mailing list             krbdev at mit.edu
Douglas> http://mailman.mit.edu/mailman/listinfo/krbdev