Subject: RE: Kerberos-revisions nits and comments

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

Below [Jbrezak]

-----Original Message-----
From: Ken Raeburn [mailto:[email-masked]] 
Sent: Wednesday, October 31, 2001 11:29 AM
To: [email-masked]
Subject: Re: Kerberos-revisions nits and comments

"John Brezak" <[email-masked]> writes:
> I don't remember that, where is it?
> [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...

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

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

[Jbrezak] Unless we can apply reply detection to both UDP and TCP, I
can't see why we should have replay detection at all in the TGS. You
might want to detect reply for logging purposes or stopping from
updating the database, etc. However the KDC should respond with a valid
response for the TGS request. Implementations can optimize this by
saving the previous reply, etc.

> [JBrezak] Is reply done with the authenticators in this case or in an 
> 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.

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

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.

[Jbrezak] We need to handle UDP and TCP the same - IMHO.

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

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

[Jbrezak] Prehaps, but I'm not sure.

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

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

[Jbrezak] Getting you to ask the kdc for a ticket encrypted in a key
that an active
attacker knows. This can then be used to get any information about you
that might
be in the authorization data or encrypted part of the ticket.

Nicolas Williams <[email-masked]> writes:
> What do MIT clients when KDCs time out? Do they resend the same KDC 
> 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: Derek Atkins <[email-masked]>
Date: 31 Oct 2001 20:37:06 -0500

> [Jbrezak] We need to handle UDP and TCP the same - IMHO.

I'm not convinced of this.  We already have to treat UDP and TCP
different in terms of retransmissions; treating them differently in
terms of replay cache is, IMHO, a related distinction.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available