Subject: [Ietf-krb-wg] Implementation rationale for KDC exchange statelessness

From: Nico Williams <[email-masked]>
Date: Tue, 14 Jun 2011 23:22:29 -0500

I would like to be able to implement multi-process and async I/O
support in the KDC in ways that fundamentally take advantage of the
statelessness of KDC exchanges.

Async I/O for things like an LDAP KDB backend can be implemented quite
simply by issuing the relevant search and queuing the current KDC-REQ
such that when the LDAP result comes in the request will get processed
from scratch again.  This requires some care to ensure that there's a
cache that will hold all the items needed such that they can be found
when the request gets processed again.  But you can see the power of
this approach: massive refactoring can be avoided in a traditional KDC
implementation.  (Of course, there may be other good reasons to code a
KDC with async I/O in mind.)

Multi-process support can be arranged such that multiple processes
listen on the same sockets such that the winner for a given request
might be a different process than the winner for the next.

I really, really appreciate the freedom to pursue such designs, and
that freedom flows from the stateless nature of KDC exchanges.

Nico
--
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simo Sorce <[email-masked]>
Date: Wed, 15 Jun 2011 08:58:30 -0400

On Tue, 2011-06-14 at 23:22 -0500, Nico Williams wrote:
> when the request gets processed again.

What you do with event systems is that you attach the requests to the
async request, so that when it is finished and the appropriate callback
is called you get all the data you need. Bonus point with event systems
that can automatically clean up stuff in case of errors.

>   But you can see the power of

You can do async and statefull at the same time, it's not too difficult,
so in all honesty I don't think the need to build a KDC in an async
fashion is a strong justification for statelessness.
I guess it can help though.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York