Pinning KDC IP addresses.
raeburn at MIT.EDU
Fri Feb 16 01:16:37 EST 2007
On Feb 15, 2007, at 23:45, g.w at hurderos.org wrote:
>> At the lowest level (krb5int_sendto), we've got support for letting
>> the caller construct the packet based on the address to send to, via
>> a callback function. But that's not used in sending to the KDC,
>> since so far we've had no need for it.
> Interesting. Did this get added in 1.5/1.6 or has it been around for
I think it was added for 1.5, and related to the password-changing
support, if I recall correctly. (The message to be sent used KRB-
PRIV or something like that where the addresses needed to be included
in the packet.)
>> Not sure what you're referring to here. Sam's "seed projects" list
>> mentioned replays, but only in improving the performance of the
>> replay cache for recording authenticators and detecting replays,
>> nothing about avoiding replays.
> I had assumed, perhaps incorrectly, that 'improvements' might mean a
> different mousetrap rather than tightening the spring on the existing
The listed project -- or at least the suggestion I was intending to
make when I put it on the list -- was just to improve the performance.
There's also been talk about a new kind of replay cache that would be
far more efficient. (For one thing, we can probably store fixed-size
hash values, which would be far faster to read, write and compare.
An on-disk representation that allows for faster searching and
expunging for the two main cases -- a single long-lived process
handling many requests, and many processes handling one request each,
both with clients that tend to be fairly well time-synchronized but
aren't always precisely so -- would also be a win. A replay cache
that can be shared across machines has also been suggested.) That's
a bigger project, especially if one wants to explore a few options,
try them out, and gather some hard data, rather than just thinking up
one approach and assuming it's the way to go.
> It seems there are two approaches to the problem. One is to figure
> out if someone is doing something to you, the other is to not let them
> do it. We took the latter approach in OTI, primarily to take replays
> against the slaves off the playing field.
So you're avoiding the attack of sending the same message to multiple
KDCs, by using the address(es) to come up with distinct messages that
can't be trivially modified to be accepted by other KDCs? Nice
approach, but I second Jeff's concerns about NAT, proxy, and tunnel
setups. How would your approach fare in those situations?
> An identity replay could be attempted against the client targetted KDC
> but the opportunity window is time constrained and the avoidance
> mechanism straight forward.
More information about the krbdev