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

From: "Paul Leach" <[email-masked]>
Date: Wed, 9 Jan 2002 10:33:55 -0800

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.

Thus, even agreeing that the field is useless for being able to extend
the current formats, I think that the simple spec would be: return error
if not 5. Since lost messages are always possible, and not
distinguishable from the behavior of some existing KDCs, no extra "what
if" handling needs to be spec'd.

Paul

> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]] 
> Sent: Tuesday, January 08, 2002 9:09 AM
> To: [email-masked]
> Subject: Re: Correct response from KDC for wrong protocol version
> 
> 
> We could conceivably use pvno!=5 for protocol changes that don't
> affect the message formats, only the field value interpretations, but
> if we want random ASN.1 parsers to work, the ASN.1 structure of the
> message can't be dependent on the values.  (Well, it might be
> possible, but only if we introduce more ASN.1 "features" that we
> aren't using already.)
> 
> But given the relative uselessness of the field, and the current
> behavior, I think we should give up on the field as wasted space.  I
> think I'd favor removing (or deprecating) the error code and not
> returning any error if pvno!=5.  It's simpler; it's one fewer option
> when implementing the KDC, and one fewer "maybe the KDC will do this"
> case to deal with on the client side.
> 
> 
> "John Brezak" <[email-masked]> writes:
> > But unless you are guaranteed a reply, of what use is it to 
> the client?
> > Also without knowing what protocol version the KDC 
> supports, the error
> > if of very limited use.
> > 
> > > -----Original Message-----
> > > From: Jeffrey Hutzelman [mailto:[email-masked]] 
> > > Sent: Monday, January 07, 2002 5:02 PM
> > > To: John Brezak
> > > Cc: [email-masked]
> > > Subject: RE: Correct response from KDC for wrong protocol version
> > > 
> > > 
> > > On Mon, 7 Jan 2002, John Brezak wrote:
> > > 
> > > > This is consistent with the MIT KDC behavior. When would it be 
> > > > beneficial for the KDC to reply with the 
> KDC_ERR_BAD_PVNO ? I can't 
> > > > see when it is useful especially since the error doesn't 
> > > suggest what 
> > > > are good pvnos for the KDC.
> > > > 
> > > > I'd prefer removing the KDC_ERR_BAD_PVNO completely and 
> > > stating that 
> > > > the KDC MUST NOT reply with anything if the pvno is not 5.
> > > 
> > > It would be beneficial to allow the KDC to reply with the 
> > > error if there are any existing KDC's that do this.
> > > 
> > > 
>

---

From: Derek Atkins <[email-masked]>
Date: 16 Jan 2002 14:52:46 -0500

> try another version if it knows of any, even if it isn't told which ones

Sounds like a DoS waiting to happen (because there would be no way
to actually authenticate this error).

-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: Nicolas Williams <[email-masked]>
Date: Wed, 16 Jan 2002 15:16:41 -0500

> to actually authenticate this error).

If you're running the KDC exchange over TCP you at least get as much
security as the TCP handshake will buy you wrt spoof DoS attacks, which
is not great, but better than with UDP. Perhaps KDC exchanges over UDP
should be deprecated [someday].

> -derek

Cheers,

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.