Subject: RE: ["Frank O'Dwyer" <[email-masked]>: Re: Kerberos login sni ffer and cracker

From: Tim Alsop <[email-masked]>
Date: Mon, 2 Dec 2002 15:51:39 -0000

>If not TLS, it seems that Kerberos should consider adapting one of the 
>other security frameworks for the initial authentication. If UDP support 
>really is required (why?) then GSS is the obvious choice. If not, SASL 
>support would also work (defining a new SASL mechanism if needed).

Larry, The reason why UDP is used (by default) for initial authentication is
that the client can fail-over to an alternative KDC for a particular REALM
if the KDC being used is busy/unavailable. When using TCP for the initial
authentication the timeout takes much longer.

Cheers, Tim.

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 2 Dec 2002 13:52:57 -0500

From: Tim Alsop <[email-masked]>
   Date: Mon, 2 Dec 2002 15:51:39 -0000 

Special offer: I will supply code, for a platform of your choosing, on
how to do application-level timeouts for TCP connections.

This is a non-issue. Applications can make the timeouts for
connections to be as long or as short as they'd like, or even
connection to KDCs in parallel.

Larry

---

From: Michael Thomas <[email-masked]>
Date: Mon, 2 Dec 2002 13:11:50 -0800 (PST)

> connection to KDCs in parallel.

   There's more to it than this. There's the issue
   of potentially introducing long term dynamic state
   to KDC's. In general, if you can avoid doing that
   you're better off. Kerberos has avoided doing that
   for 10 years and I think there's a lot of value keeping
   it that way.

	   Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 2 Dec 2002 13:26:59 -0800 (PST)

Lawrence Greenfield writes:
 >    From: Michael Thomas <[email-masked]>
 >    Date: Mon, 2 Dec 2002 13:11:50 -0800 (PST)
 > [...]
 > The WG has already come to consensus that clarifications are requiring
 > KDCs to support the TCP transport.

   Um, so? That doesn't mean that they have to *use*
   it as the preferred transport. Indeed, quite the
   opposite.

		Mike

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 2 Dec 2002 16:19:45 -0500

<[email-masked]>
<[email-masked]>
Content-Type: text/plain; charset=US-ASCII
Sender: [email-masked]
Precedence: bulk

Larry

---

From: Martin Rex <[email-masked]>
Date: Tue, 3 Dec 2002 23:15:38 +0100 (MET)

> connection to KDCs in parallel.

It is an issue.  The size of code is also a robustness/reliability
issue, as well as the amount of state that is kept and the amount
of resources that are consumed.

TCP was added to allow for tickets of ridiculously huge sizes.

With TCP, you have the timeout problem not only during connect/accept,
but also anywhere in between the data transfer.  And there's usually
a relatively low limit of open file handles (for the server).

With UDP, the server receives the whole request with a single read.
So you can get along with the OS'es buttons to manage resource consumption
and limits of network (reassembly) buffers and don't have to duplicate
all that in the application code as is necessary when using TCP.

-Martin