Subject: serious problems in sec 3.2.3 (AP-REQ handling)

From: Tom Yu <[email-masked]>
Date: Tue, 08 Oct 2002 21:03:13 -0400

It has recently come to my attention that the MIT krb5 implementation,
possibly following rfc1510 a little too closely, rejects
authenticators as replays even though they are different from each
other.  This is a serious problem for clients that issue rapid-fire
requests.  Section 3.2.3 requires that the replay cache store the
client name, service name, time, and microseconds.  Section 3.2.3
further specifies that KRB_AP_ERR_REPEAT is returned if these fields
match between two authenticators.

I know of no cryptographically valid reason why the replay cache
should not store the entire encrypted authenticator and use that to
detect replays.  The way section 3.2.3 currently reads, legitimate
requests having different authenticators may be rejected if the client
happens to generate the same time and microseconds field twice for
different requests.  This might be a particular problem for Windows
implementations, since I seem to recall that the PC hardware clock
only has a resolution of 55 milliseconds, and modern hardware is quite
capable of producing multiple AP-REQ messages within that time frame.
This is probably not a problem for Unix-based systems, since my belief
is that historically, the gettimeofday() system call will always
return monotonically increasing values of tv_usec for multiple calls
during the same second, regardless of whether the callers are
different processes.

I would suggest changing the text in 3.2.3 to remove the overly strict
requirement on replay detection, instead relying on comparison of the
complete encrypted authenticators.  There should probably be an
implementation note (in section 3.2.1?) cautioning that some
implementations only check the client name, server name, time, and
microseconds without comparing the encrypted authenticators; client
implementations should therefore attempt to ensure that at least the
microseconds fields of authenticators are always different between
legitimately different requests issued in the same second.

Does anyone believe that this change would introduce any security
vulnerabilities?

---Tom

---

From: Clifford Neuman <[email-masked]>
Date: Tue, 8 Oct 2002 21:38:31 -0700

Tom,

I notice that there is still mention of the canonicalize option in
section 5 in the description of the realm field.  Can you remove this
mention.  I also would like us to add the option canonicalize in the
reserved options (i think as option 15) but with a note that says this
is reserved for future use (still named canonicalize) and is not
supported in clarifications.

Cliff

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Oct 2002 18:23:22 -0400

I talked to Tom today and I think convinced him that we should not
block the document on this change, and we should not change the
protocol.  My reasoning is that there is an acceptable way to follow
the current protocol so we should not change it for clarifications.

We may want to add an implementation note indicating that
implementations should make sure they do not reuse microseconds,
possibly bumping microseconds if needed.