kprop with multiple or NATted IP address

[Jerry Shipman]

I am continuing (sorry) my old 2016 thread (part of it below) about trying to kprop through a NAT. 

I have some secondary KDCs in a different network than the primary, with a NAT in the way, and was having trouble getting kprop to work (it doesn't like the mismatch between the IP from the hostname dns lookup and the IP in the getsockname(), or something like that). 

I wound up working around it by periodically dumping the database, copying it over to the secondaries, and importing it.
But this workaround is causing some other trouble (the master database is locked for a noticeable amount of time during the periodic exports). 

Can you tell me if there has already been, or if there might be in the near future, a plan to update kprop to let it work (maybe with a command line switch or something) through the NAT, so that I can do incremental propagation through the NAT?

Or, maybe there is some way that I can fake out the name resolution (using /etc/hosts or dnsmasq or something) to make it work -- is that a reasonable thing to try?

Or, one of my co-workers suggested that I make a cron job to scan for recent password changes and dump/import just those, periodically (instead of doing the full database dumps). I can do that and I guess it would work... but it would be nice to not do that.

Or is there some better idea that we didn't think of?

Thank you again for your help,
Jerry


-----Original Message-----
From: Greg Hudson <ghudson at mit.edu>
Date: Thursday, December 24, 2015 at 12:21 AM
To: "Jeremiah E. Shipman" <jes59 at cornell.edu>, "kerberos at mit.edu" <kerberos at mit.edu>
Subject: Re: kprop with multiple or NATted IP address

On 12/23/2015 03:50 PM, Jerry Shipman wrote:
> Is there a way to do what I’m trying to do?
> Or, is there a reason that it is dangerous to avoid verifying that IP match, and I shouldn’t try to work around it?

The only really useful purpose of checking addresses is preventing
reflection attacks, where an attacker takes a KRB-PRIV or KRB-SAFE
message from one of the parties and send it back to them as if it came
from the other party.  Many protocols aren't susceptible to reflection
attacks because they don't use similar formats for requests and
responses.  After verifying that the kprop protocol isn't vulnerable, we
could probably make changes similar to the ones we made to kpasswd to
allow it to work over NATs.

(Protocols using GSS don't have this problem because GSS tokens only use
direction bits, not addresses.  Well, unless they use IP address channel
bindings, which isn't common.)