Subject: RE: Kerberos over TCP/IP

From: "Renard, Kenneth" <[email-masked]>
Date: Tue, 27 Jan 1998 15:41:53 -0500

A KDC_ERR_PENDING message would be pretty useful for high-latency
transactions such as One-Time-Password (OTP) pre-authentication.
Current scenario:
	
	AS client (kinit) sends request to primary KDC
	Primary KDC starts up high-latency preauth check (e.g. SecurID
code)
	AS client times out and sends request to secondary KDC
	Secondary KDC starts preauth check [This is now the 2nd time the
OTP is
		used, the 2nd attempt will fail, the 1st attempt may
fail now too]
	Race to see which KDC (primary KDC with auth success(?) or
secondary with 		failure) comes back first

A KDC_ERR_PENDING message would do the trick.  Should this type of
message [and timeout value] be signed by the KDC (encrypted with user
key)?

Unfortunately, for all AS and TGS transactions, the KDC process blocks.
If KDC throughput is an issue, you want to stay away from these.  Anyone
want to write a Multi-Threaded KDC??

-Ken Renard

> ----------
> From: 	Mike Swift (NT)[SMTP:[email-masked]]
> Sent: 	Tuesday, January 27, 1998 1:13 PM
> To: 	[email-masked]
> Subject: 	Kerberos over TCP/IP
> 
> 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: Ken Hornstein <[email-masked]>
Date: Wed, 28 Jan 1998 22:34:56 -0500

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

And I have yet to understand why SecurID takes so long to perform
authentication, anyway :-)

--Ken