Subject: RE: Kerberos over TCP/IP

From: "Mike Swift (NT)" <[email-masked]>
Date: Thu, 29 Jan 1998 10:39:32 -0800

True, it is a rathole. However, will the Kerberos protocol function with the
new heavyweight extensions if something like this isn't added? I know DCE
went to RPC for the KDC, which resolves all these problems. The question is
how best to fix this for MIT kerberos - incrementally adding robustness
features or switch wholesale to a new transport protocol.

-----Original Message-----
From: Richard Salz [mailto:[email-masked]]
Sent: Thursday, January 29, 1998 10:34 AM
To: [email-masked]; [email-masked]; Mike Swift (NT)
Cc: [email-masked]; [email-masked]
Subject: RE: Kerberos over TCP/IP

>The Microsoft KDC is multi-threaded and may need to support longer-running
>requests - hence my interest in adding a pending message. In addition, I
>think the error for indicating that the response message is too big to fit
>in a UDP message is useful unless clients know to try TCP first, which they
>may not want to for performance reasons.

This sounds like a big step down the slippery slope of re-implementing
an industrial-strength RPC system.  I don't think it's something
for this working group or this specification.
	/r$

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 29 Jan 1998 16:36:49 -0500

To inject some facts into the discussion, the decision to have DCE use
RPC in addition to (not instead of!) UDP/IP for KDC communication was
in many ways a political one and had nothing to do with the size of
the messages possible over UDP, or other properties of the transport
protocol.

DCE was intended to be transport-protocol independant, with all the
per-transport-protocol hair localized within RPC and all communication
done over RPC.  Sort of like IP, only at a slightly higher layer in
the stack.

So, in the case of Kerberos, the byte string containing the datagram
to be sent via UDP was instead passed as a byte array parameter in an
RPC...

I question the wisdom of bloating kerberos messages to the point where
they won't fit in a sub-path-MTU udp datagram... but if you have to do
that, the Right Answer is clearly to just use TCP...  but that adds
significant complexity to the KDC due to (among other things)
connection management and flow control issues..

				- Bill
				(DCE implementor...)