Subject: RE: Kerberos-revisions nits and comments

From: "John Brezak" <[email-masked]>
Date: Wed, 31 Oct 2001 09:29:49 -0800

Below = [JBrezak]

-----Original Message-----
From: Ken Raeburn [mailto:[email-masked]] 
Sent: Tuesday, October 30, 2001 7:24 PM
To: [email-masked]
Subject: Re: Kerberos-revisions nits and comments

"John Brezak" <[email-masked]> writes:
> 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,

I don't remember that, where is it?

[JBrezak] Footnote 3.5 in section 3.

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

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.

[JBrezak] There needs to be a clear definition of "sensibly". The
pseudo-code presumes that reply detection is done for tgs requests. The
MIT code apparently does no reply detection in the TGS. With the
introduction of the TCP transport, what should be done for replay
detection?

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.

[JBrezak] Is reply done with the authenticators in this case or in an
authenticator in the preauth data?

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.

[JBrezak] So are you saying that we should not need to perform replay
detection for the base protocol? If so this needs to be clear in the
spec text and pseudo-code. There should also be some commentary on reply
requirements for PA extensions needs to be considered.

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

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.

[JBrezak] Isn't there an attack possible if the suggested kvno is sent
in the clear and not bound to the request?

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

[JBrezak] The message from the server would have to be
checksumed/encrypted with the server's key before the KDC should believe
it - right?

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Oct 2001 13:43:06 -0500

With UDP, the network may deliver duplicates to the KDC, therefore the
KDC has little choice: drop dups or respond to dups (presumably with a
cached reply). Responses by the KDC can also be duplicated by the
network, so the latter approach makes sense.

With TCP you cannot get accidental replays in a single TCP session, and
each session, being different from past ones (different ISNs), also
cannot be an accidental replay.

Therefore, doing replay detection on TCP TGS requests makes sense, but
with UDP it's best to log the replay and replay the original response.

What do MIT clients when KDCs time out? Do they resend the same KDC
request? or do they generate a new request?

Nico

--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

---

From: Ken Raeburn <[email-masked]>
Date: 31 Oct 2001 14:29:23 -0500

> [JBrezak] Footnote 3.5 in section 3.

Ah, yes, thanks.  It's correct, as far as it goes, but similar caveats
apply to distributed servers sharing a service principal name across
machines.

But on the flip side, sometimes it makes sense to review the cost of
not bothering to detect replays.  Aside from certain preauth
situations, we aren't talking about exchanges that alter database
entries in any interesting way, are we?  Or access to any interesting
resources?  I think that just leaves the crypto-attack issue...

> introduction of the TCP transport, what should be done for replay

The "lookaside" cache code, when enabled, intercepts all messages (AS,
TGS, and krb4 AS and TGS) that have been seen before, and resends the
previous result, before the regular krb5 library replay cache code
(which just reports an error when duplicates are seen) gets to look at
it.  (The former looks for an exact match, the latter compares certain
field values as specified by the RFC.  So it's possible for a message
to miss one and hit the other.)

In the TCP case, you won't get accidental replays, but a client may
have to connect a second time if it doesn't get a response from the
first TCP session (because of network lossage, timeout, whatever).

My feeling is that intentional reconnects with TCP should be looked at
as new message exchanges, but under UDP the client shouldn't have to
worry about getting replay-attack errors because of some duplication
in the sending path and dropped packets or out-of-order delivery on
the return path.  If the KDC always allows resent UDP messages, the
client can optimize a little by not building new messages for UDP
retransmits.  But that's not particularly consistent, in terms of KDC
behavior, unless we specifically make the point that the application
can choose to take other approaches to replay handling.  (I think that
it'd be stretching things just a bit to say that choosing not to care
qualifies as "suitable means to protect against replay" [section
3.2.3].)

> authenticator in the preauth data?

The reply sends whatever was sent before.  At that level, it doesn't
care what the messages are, it doesn't even bother to parse them.

> requirements for PA extensions needs to be considered.

I'm saying it looks like a tradeoff to me -- theoretical security
versus practical concerns -- and that MIT's code, at least lately, has
not performed the replay detection as specified in the draft alone;
either none at all, or an extra layer of checks comes first.  But we
should specify it at least enough so that the required behavior of
both client and KDC under UDP is clear.

> in the clear and not bound to the request?

Maybe.  Is it any more than a denial of service for the one exchange?

> checksumed/encrypted with the server's key before the KDC should believe

I'm not sure.  What's the exposure if we don't protect it?

> request? or do they generate a new request?

Currently they resend the same message -- we lay out the packet and
then call the "send to KDC and wait for reply" routine, which loops
through the KDC list some number of times.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Oct 2001 15:03:55 -0500

> through the KDC list some number of times.

I see.

I see a large number of retransmits. Perhaps the MIT client timeout
strategy needs tweaking (this belongs on a different list, I know).

Nico