Subject: Re: Section 3 Kerberos Revisions for comment

From: Ken Raeburn <[email-masked]>
Date: 21 Sep 2000 19:08:28 -0400

Sorry these are so late...

Section 3.1.3:

Canonicalization of the server name is not allowed in this case?  The
procedure is laid out in such detail that that's the only conclusion I
can reach from the omission.

It should be noted somewhere that the client name canonicalization is
(apparently) completely insecure, and should not be trusted by any
privileged software without verification.

The description of the calculation of the expiration time is in my
opinion too implementation-oriented.  Why can't a minimal
implementation set a fixed max lifetime on all tickets, and not
associate any lifetime limits with specific principals?  I'd be more
comfortable with these items described as examples of factors an
implementation might use to impose constraints on the ticket lifetime.

Section 3.2.3:
> returned[11].  The server must remember any authenticator presented
> within the allowable clock skew, so that a replay attempt is
> guaranteed to fail.  If a server loses track of any authenticator
> presented within the allowable clock skew, it must reject all requests
> until the clock skew interval has passed.  This assures that any lost
> or re-played authenticators will fall outside the allowable clock skew
> and can no longer be successfully replayed (If this is not done, an
> attacker could subvert the authentication by recording the ticket and
> authenticator sent over the network to a server and replaying them
> following an event that caused the server to lose track of recently
> seen authenticators).  If a sequence number is provided in the

Minor nit: The parenthetical construct should be its own separate
sentence, not stuck into the previous one.

Technical stuff: There are other ways the application can avoid replay
attacks without maintaining any such record of previous
authenticators.  I don't think such an application should be
considered noncomplaint with the Kerberos spec; we could weaken the
wording here just a little.  Something like:

  Unless the application server has other means to prevent such replay
  attacks (for example, a challenge-response sequence initiated by the
  server after authentication, or use of a server-generated encryption
  subkey), [...must remember authenticators, delay startup, etc...]
  Careful analysis of the application protocol and implementation is
  recommended before eliminating this cache.

On the other hand, I would also suggest adding something like this:

  If multiple servers (for example, different services on one machine,
  or a single service implemented on multiple machines) share a
  service principal (a practice we do not recommend in general, but
  acknowledge will be used in some cases), they should also share this
  replay cache, or the application protocol should be designed so as
  to eliminate the need for it.  Note that this applies to all of the
  services, if any of the application protocols does not have replay
  protection built in; an authenticator used with such a service could
  later be replayed to a different service with the same service
  principal but no replay protection, if the former doesn't record the
  authenticator information in the common replay cache.

> be encrypted[16].  If the sub-session key is not specified, the

Once again, the footnotes should be included with these mailings....

Section 3.3.3, next to last paragraph:
> ticket passes the hotlist check described in the next paragraph, the
> KDC will issue the appropriate new ticket.

Should be "next section".

Section 3.3.3.2:

Does either style of realm name permit a "root" realm?  If so, how are
these roots encoded for compression?

----------------------------------------------------------------
Guess that's it for now...

Ken