Subject: RE: Kerberos-revisions nits and comments

From: "John Brezak" <[email-masked]>
Date: Thu, 1 Nov 2001 20:10:02 -0800

So what is the value of replay detection for the TGS? If it cannot be
done reliably with UDP and TCP and there are not associated new risks
should it be specified as necessary?

-----Original Message-----
From: Derek Atkins [mailto:[email-masked]] 
Sent: Thursday, November 01, 2001 7:14 AM
To: John Brezak
Cc: Ken Raeburn; [email-masked]
Subject: Re: Kerberos-revisions nits and comments

Perhaps..  But there are other tools than just the KDC itself to notice
and prevent such attacks.  For example, if I wanted to I could just keep
sending random packets to a KDC to flood the network.  Or I can make
many random TCP connections in order to flood it.  The attacks are
similar, but need to be tuned to the transport.

Since the transports provide different retransmission guarantees, I
think we need to live with the consequences of it.  For example, you
KNOW that with TCP you WILL NOT get a duplicate request, at least within
the same TCP session.  You KNOW that the network will not send a
duplicate packet.  So, what exactly does replay protection buy you here?

Step back and ask yourself: what attacks are you trying to protect
yourself against with replay protection on the KDC?  While you are
answering this, keep in mind that there _are_ legitimate reasons for a
UDP client to retransmit a request to the KDC, and there are even
reasons for a TCP client to retransmit (but not as many ;)

-derek

"John Brezak" <[email-masked]> writes:

> If replay detection is different (or non existent) on UDP, wouldn't an

> attacker choose to use UDP over TCP in searching for weakness?
> 
> -----Original Message-----
> From: Derek Atkins [mailto:[email-masked]]=20
> Sent: Wednesday, October 31, 2001 5:37 PM
> To: John Brezak
> Cc: Ken Raeburn; [email-masked]
> Subject: Re: Kerberos-revisions nits and comments
> 
> 
> "John Brezak" <[email-masked]> writes:
> 
> > I'm saying it looks like a tradeoff to me -- theoretical security=20

> > versus practical concerns -- and that MIT's code, at least lately, 
> > has
> 
> > not performed the replay detection as specified in the draft 
> >alone;=20  either none at all, or an extra layer of checks comes 
> >first.  But we=20  should specify it at least enough so that the 
> >required behavior of=20  both client and KDC under UDP is clear. =20
> > [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
> 
> --=20
>        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

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

---

From: "John Brezak" <[email-masked]>
Date: Mon, 5 Nov 2001 19:51:16 -0800

I'm proposing that we remove replay detection from the TGS and change
the kerberos-revisions including the pseudo-code to illustrate this.
Since the behavior of the TGS must be the same for replay detection
between UDP and TCP, there doesn't seem to be a valid mechanism except
to reply with a valid ticket for alleged replays.

Objections/reasons?

-----Original Message-----
From: Derek Atkins [mailto:[email-masked]] 
Sent: Thursday, November 01, 2001 7:14 AM
To: John Brezak
Cc: Ken Raeburn; [email-masked]
Subject: Re: Kerberos-revisions nits and comments

-derek