Pinning KDC IP addresses.

[g.w@hurderos.org]

On Feb 15,  2:35am, Ken Raeburn wrote:
} Subject: Re: Pinning KDC IP addresses.

Good evening Ken, thanks for the note.

> On Feb 15, 2007, at 01:28, g.w at hurderos.org wrote:
> > In the current MIT codebase packetization of the AS_REQ occurs well
> > before transmission of the request.  As a result it is somewhat
> > difficult to modify the payload to coincide with the IP address of the
> > KDC being targeted by the krb5_sendto routine.
> >
> > The most straight forward strategy would seem to be to push
> > packetization downward into the krb5_sendto_kdc function.  If
> > packetization were delayed until after IP address selection was
> > completed the address could be made available to a plugin for final
> > payload modification before transmission.  It would seem straight
> > forward to accomplish this by passing the krb5_kdc_req structure
> > pointer all the way down to the krb5_sendto_kdc function.

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

We are still developing against 1.4.4 and have studied the send
callstack all the way into krb5int_sendto.  Based on what I'm looking
at it isn't obvious how to pass in a callback function pointer in
order to get a shot at re-packetizing the krb5_kdc_req structure just
prior to pitching it over the socket.

If its in 1.4.x I must be missing something obvious.

> > Sam mentioned in his outline that a more efficient replay avoidance
> > implementation was being considered as part of future development
> > plans.  The ability to more precisly pin requests to a KDC would seem
> > to be a positive move toward a more robust replay avoidance strategy.

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

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.

An identity replay could be attempted against the client targetted KDC
but the opportunity window is time constrained and the avoidance
mechanism straight forward.

> Ken

Thanks for the insight, have a good weekend.

}-- End of excerpt from Ken Raeburn

As always,
Greg Wettstein

------------------------------------------------------------------------------
			 The Hurderos Project
         Open Identity, Service and Authorization Management
                       http://www.hurderos.org

"Academic freedom is not chaos."
                                -- Shelby Williams