Subject: Kerberos-revisions nits and comments

From: "John Brezak" <[email-masked]>
Date: Thu, 25 Oct 2001 16:35:03 -0700

1) I notice that the rfc-1510 pseudo-code has replay detection in the
TGS-REQ verification section. In 1510bis, there is some discussion about
replay detection in the TGS saying that you can't really do this
reliably in UDP, but the pseudo-code still has it. It would be great to
be clear if replay detection is really needed in the TGS and specify
what is to be done for both the UDP and TCP cases.
 
2) How is PA-USE-SPECIFIED-KVNO to be used? Is this to be used in
conjunction with a krb-error(KRB-AP-ERR-BADKEYVER) from a failed AP-REQ
to a server? If so how does the server communicate the specified kvno to
the client so that it can discard the current ticket and request a new
one for the server with the PA-USE-SPECIFIED-KVNO?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

John Brezak                       * mailto:[email-masked]

Microsoft Corporation        ( 425-706-2602

One Microsoft Way

Redmond, WA 98052

---

From: Ken Raeburn <[email-masked]>
Date: 30 Oct 2001 22:24:02 -0500

"John Brezak" <[email-masked]> writes:
> reliably in UDP,

I don't remember that, where is it?

>   but the pseudo-code still has it. It would be great to

Clearly, given that packets may be lost and the client may have to
retransmit, and given that packets may be duplicated in transit, the
server may well get what appear to be replayed messages in reasonable
circumstances.  (In the former case, I don't think we've ever been
explicit as to whether the client should generate new timestamps so as
to explicitly make it not look like a replay.)  The KDC should behave
sensibly in that case.

There are, I understand, some preauth schemes where treating the
second message in an apparent-replay situation as unrelated to the
first can cause the preauth mechanism to get confused.  (One of the
hardware token based preauth systems, I forget which.)  The MIT
approach to this has been an extra sort of replay cache which notices
the message coming in again, and retransmits the same response,
without going through the preauth support code path (or the regular
replay cache code path) again.

On the other hand, if you're not using such preauth schemes, and an
attacker resending the messages doesn't actually have the client's
key, what's the cost if you ignore the replay and process the message
again?  Some CPU time, and exposing a little more data encrypted in
the client key.  CPU time is not an important issue so far in the MIT
implementation, but probably important for Microsoft.  Exposing more
ciphertext with highly predictable plaintext using the client's
long-term key is a problem in theory, certainly, if the attacker can
do it thousands of times, but is it a practical problem?  On the third
hand(?), depending on the quality of the implementation, the replay
cache itself can be expensive.  In the non-preauth setup, we've
sometimes disabled all replay checking in our KDC.

> one for the server with the PA-USE-SPECIFIED-KVNO?

From section 5.2.7.3, I'd say it's a message for the client to send
with an AS-REQ message, not useful (as currently specified) for the
application protocol case.

But there might be a way to make it useful in this case too.  Perhaps
the application server could send back a TypedData sequence with a
TD-PADATA element containing PA-USE-SPECIFIED-KVNO, causing the client
to contact the KDC and send that same PA datum...

Ken