Subject: RE: Kerberos over TCP/IP

From: "Renard, Kenneth" <[email-masked]>
Date: Thu, 29 Jan 1998 10:40:39 -0500

> >A KDC_ERR_PENDING message would be pretty useful for
high-latency
	> >transactions such as One-Time-Password (OTP)
pre-authentication.
	> 
	> I thought that one of the design criteria of the KDC was that
it
	> it was stateless ... it looks like to me that adding this
would require
	> keeping track of state to the KDC.

Not necessarily.  This merely injects a message from KDC to client
during the KDC processing of the AS_REQ.  The KDC does not return to
process any new requests until the entire transaction has been
completed.  As I mentioned, this may be painful since the KDC process
will block during the external processing.  This message will keep
clients from timing out or issuing further requests to KDCs (and
possibly blocking them too).

Certificate verification and signing operations can add up to a
fair-sized latency for extensions such as PK-INIT and PK-CROSS.  Have
implementations of these protocols seen any "problems" due to this
latency?  Client retry and throughput issues creep into the picture when
the AS_REQ processing gets more sophisticated.

Hmmm... a multi-threaded KDC sounds pretty cool!  Any ideas/issues?

	> --Ken

-Ken R.

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 29 Jan 1998 12:33:18 -0500

>Hmmm... a multi-threaded KDC sounds pretty cool!  Any ideas/issues?

I'm not sure this is appropriate for cat-ietf, buuuttt ...

Currently under Unix, threads present portability problems.  If you're
using one of the many userspace threads packages, you probably shouldn't
even bother, since they're non-preemptive and you'll just end up with
an event-driven KDC like you have now.

Even when you have kernel support for threads, the implementations I've
seen don't actually get you concurrency unless you have a multiprocessor
machine.

--Ken