Pinning KDC IP addresses.

[Ken Raeburn]

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
> awhile?

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

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.

Yes.

Ken