Subject: RE: Kerberos over TCP/IP

From: "Mike Swift (NT)" <[email-masked]>
Date: Thu, 29 Jan 1998 09:16:05 -0800

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.

- Mike
-----Original Message-----
From: Renard, Kenneth [mailto:[email-masked]]
Sent: Thursday, January 29, 1998 7:41 AM
Subject: RE: Kerberos over TCP/IP 

...

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

	> --Ken

-Ken R.

---

From: Richard Salz <[email-masked]>
Date: Thu, 29 Jan 1998 13:33:30 -0500 (EST)

>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: Richard Salz <[email-masked]>
Date: Thu, 29 Jan 1998 13:57:21 -0500 (EST)

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

I believe the best fix is to say "use another protocol" or "try TCP first."
This can be a "note to implementors" part of the spec.

I firmly believe this WG should not start down this path.  The slope is
way too steep.  Adding "in progress" (I prefer the ISO RPC name indy,
for I'm Not Dead Yet:) packets is a big step toward breaking the lockstep
request/reply nature of the protocol.  Especially because within 48 hours
of accepting this concept, someone will say that they are developing a
smart client and would like to ping the KDC themselves.  Etc.  The
slippery slope has a pretty steep slope, in my view.
	/r$

---

From: "Mike Swift (NT)" <[email-masked]>
Date: Sat, 7 Feb 1998 18:33:25 -0800

Works for me. The KDC can always return the KDC_ERR_RESPONSE_TOO_BIG to a
client if it wants the client to switch from a datagram protocol to a
connection oriented protocol, which removes some of the need for short
timeouts. I'll add this to the issues list at gost.isi.edu.
 
- Mike

-----Original Message-----
From: Theodore Y. Ts'o [mailto:[email-masked]]
Sent: Friday, February 06, 1998 7:16 PM
To: Mike Swift (NT)
Cc: [email-masked]
Subject: Re: Kerberos over TCP/IP

   From: "Mike Swift (NT)" <[email-masked]>
   Date: Tue, 27 Jan 1998 10:13:52 -0800

   I think that we should add a method for the KDC to return an error to the
   client indicating that the client needs to use a different transport. For
   example, if the client tries to do PKINIT over UDP and the KDC discovers
   that the response won't fit in a datagram, the KDC should be able to
return
   an error indicating that the client should switch to TCP. We don't
   necessarily need to code exactly that message, but perhaps a new error
code,
   such as KDC_ERR_RESPONSE_TOO_BIG, indicating that the transport can't
handle
   the size of the response. The client would then be responsible for
finding a
   transport that could handle a larger message.

This sounds like a good idea to me.

   In addition, another scenario in which the KDC would want the client to
   change transports is if it knows it won't be able to respond within the
   timeout for UDP. It is conceivable that with PK-CROSS, in which the KDC
may
   need to locate and communicate with a KDC in another realm, that it won't
be
   able to respond within the client's timeout. Perhaps we could formalize a
   mechanism for the KDC to return a keep-alive, indicating that the client
   should wait longer. One way to do this would be for the KDC to return a
   KRB-ERROR message with an error KDC_ERR_PENDING, and a e-data value
   indicating how long the client shoud wait. That would allow longer
running
   transactions to work reasonably over UDP.

I agree with some of the concerns which Rich has mentioned.  I'll also
note that if you're using public key operations to establish a
cross-realm key which can then be cached for multiple operations, the
situations where you can't repsond within the client's timeout is
relatively rare.  If in those circumstances the client retries a couple
of times before you finally get the response to the client, it's not the
end of the world, since the the extra tries (once your initial one
succeeds) will get handled quite quickly.

So I'm not really sure KDC_ERR_PENDING is really needed in practice.

Note, though, that KDC_ERR_PENDING doesn't require adding state to the
KDC, as Ken suggested.  It requires that the client code have a bit more
state, since when it sees the KDC_ERR_PENDING, it needs to then take
appropriate action.

In general, if we are adding so many heavy-weight extensions to the
Kerberos protocol, at some point we should stop and reexamine what we're
doing, and whether the additional features are really good ones.  It's
very easy to get catch OSI disease, aka featurities leading to a
terminal case of protocol-complexity....

						- Ted