kprop with multiple or NATted IP address

[Jeffrey T. Hutzelman]

Rather than making complex changes to the protocol, why not switch to directional addresses? Certainly the client and server would have to agree on this, but for kprop, a command-line switch would be sufficient.


-- Jeff


________________________________
From: kerberos-bounces at mit.edu <kerberos-bounces at mit.edu> on behalf of Greg Hudson <ghudson at mit.edu>
Sent: Friday, January 3, 2020 11:53 AM
To: Jerry Shipman; kerberos at mit.edu
Subject: Re: kprop with multiple or NATted IP address

On 1/3/20 11:00 AM, Jerry Shipman wrote:
> I am continuing (sorry) my old 2016 thread (part of it below) about trying to kprop through a NAT.

Apologies that I didn't follow up on that.  In that thread, I wrote:

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

I took at look at the kprop protocol just now.  Unfortunately, kprop and
kpropd use  the same format for the client-to-server and
server-to-client KRB-SAFE messages, and on successful completion the
payloads are expected to be identical.  (KRB-PRIV messages only flow
from client to server.)  So without protection from reflection attacks,
an attacker could potentially make a failed transmission look like a
successful transmission by reflecting the client's KRB-SAFE message.

I think that sequence numbers would generally thwart this attack, since
kprop and kpropd use mutual authentication and enable sequence number
checking.  But I would have to do some additional analysis to be
confident about that; these sequence numbers are only 32 bits, and there
is some fudging around past implementations which further reduces the
margin of safety.

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

Fortunately, we have a couple of workarounds for this secondary problem.

Release 1.13 added support for unlocked database dumps with the db2 KDB
module: "kdb5_util -x unlockiter dump".  This will make the dump command
take longer, but not keep the database locked.

Release 1.17 added the lmdb KDB module, which does not suffer from
locking conflicts between dump operations and write operations.
________________________________________________
Kerberos mailing list           Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos