Forking the KDC

["Henry B. Hotz" <hotz@jpl.nasa.gov>]

I have a couple of use cases where it might be necessary to delay an  
AS-REP by long enough to affect overall server performance.  Can  
anyone knowledgeable comment on the feasibility of doing it as follows:

1) complete processing to the point where the AS-REP is constructed,  
and hdb locks are released.
2) fork -- main erases knowledge of reply socket, and AS-REP storage  
and return to main loop
	-- slave does the following
3) wait
4) send AS-REP, and finish processing cleanup
5) end slave

Does it sound feasible that the resources involved could be narrow  
enough that this kind of fork could be done?

For those who were wondering, the simplest example that would need  
this is an intentional delay in responding to failed (pre-auth  
failed, to be precise) authentication attempts.  The intent is to  
slow down naive, brute-force attackers, and maybe get some DOS  
robustness as well.

Another possible application would be if you need to consult an  
external (possibly slow) service before granting a tgt.  In this case  
I'm guessing you would construct both successful and unsuccessful AS- 
REP's before the fork so you can release the database.
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu