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

From: "John Brezak" <[email-masked]>
Date: Mon, 7 Jan 2002 17:12:10 -0800

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: Ken Raeburn <[email-masked]>
Date: 08 Jan 2002 12:08:45 -0500

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.