Subject: RE: Correct response from KDC for wrong protocol version

From: "Paul Leach" <[email-masked]>
Date: Wed, 16 Jan 2002 16:59:21 -0800

> -----Original Message-----
> From: Derek Atkins [mailto:[email-masked]] 
> Sent: Wednesday, January 16, 2002 11:53 AM
> To: Paul Leach
> Cc: Ken Raeburn; [email-masked]
> Subject: Re: Correct response from KDC for wrong protocol version
> 
> 
> "Paul Leach" <[email-masked]> writes:
> 
> > Returning an error instead of dropping the message on the 
> floor will 
> > tell the client not to retry, saving it (say) 30 seconds of 
> retrying 
> > before it gives up. If the error is fast, it's even 
> reasonable it can 
> > try another version if it knows of any, even if it isn't told which 
> > ones the KDC supports.
> 
> Sounds like a DoS waiting to happen (because there would be 
> no way to actually authenticate this error).

Good point. But aren't there lots of other non-authenticatable errors
the attacker could return in this scenario, that would also cause the
client to give up? How about "principal not found"?

Paul

---

From: Derek Atkins <[email-masked]>
Date: 16 Jan 2002 20:04:24 -0500

> client to give up? How about "principal not found"?

A principal not found error can be signed (at least in response to a
TGS_REQ).  How do you know how to format an error response to an
invalid protocol version?

I suppose that, yes, there are some errors the KDC just wont be
able to sign, but none of these errors should cause the client
to just stop trying.

> Paul

-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

---

From: Derek Atkins <[email-masked]>
Date: 16 Jan 2002 20:04:24 -0500

-derek