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

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.

- Mike

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Fri, 6 Feb 1998 22:15:49 -0500

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

This sounds like a good idea to me.

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

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 09 Feb 1998 01:46:51 -0500

>state, since when it sees the KDC_ERR_PENDING, it needs to then take

Errr, _which_ Ken? :-)

The situation where I ran into a problem that _might_ have been
able to use this was where I was using a hardware token for preauth,
and to validate the token code you had to call a library function
which talked to the card vendor's authentication server ... and
this authentication server had a BUILT-IN 2 second delay.  _And_
if you retried and sent multiple queries (for example, your client
timed out and talked to a slave KDC) then the card authentication
server would respond with an error (because it had already seen
that code) and you ran about a 30 percent chance of getting an
error returned to the client by the slave before the master had a
chance to compute the response.

I ended up fixing this by ditching this particular hardware token
vendor :-)  However, KDC_ERR_PENDING might have helped with this ...
but I think it would have been too hard, since it would have
required more master/slave coordination.

--Ken