Subject: RE: Handling of krb_error checksums

From: "John Brezak" <[email-masked]>
Date: Thu, 24 Jan 2002 09:20:42 -0800

below.

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Wednesday, January 23, 2002 5:05 PM
> To: John Brezak
> Cc: [email-masked]
> Subject: Re: Handling of krb_error checksums
> 
> 
> >>>>> "John" == John Brezak <[email-masked]> writes:
> 
>     John> As long as the typed hole for e-data is preserved. We also
>     John> need to move forward on at least the use of TypedData for
>     John> constructing the e-data in the krb-error.
> 
> e-data isn't a typed hole, that's the problem.

Isn't the TypedData construct for e-data as described in the RFC and I-D
a typed hole? There are some cases (legacy) where the TypedData is not
used in e-data and those need to be accomodated. Win2000 and XP have a
case where TypedData is not used.

> 
>     John> Also one other observation - for the "2" messages can the
>     John> protocol version number be moved (copied) to the outer asn.1
>     John> encoding that contains the checksum? This would make the
>     John> protocol version number useful in the future. Same is true
>     John> for the ticket version number.
> 
> I think so.  I believe the reason this was not done is that 
> you and Matt were expected to object and it didn't seem worth 
> arguing over. Tom, comments?

If we are to move forward with the "2" proposal, then it does make sense
to place vno data in the outer encoding. I'm fine with having the vno
there - I'm still working on costing for the "2" proposal.

---

From: Tom Yu <[email-masked]>
Date: 24 Jan 2002 15:11:59 -0500

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

John> below.

>> e-data isn't a typed hole, that's the problem.

John> Isn't the TypedData construct for e-data as described in the RFC
John> and I-D a typed hole? There are some cases (legacy) where the
John> TypedData is not used in e-data and those need to be
John> accomodated. Win2000 and XP have a case where TypedData is not
John> used.

e-data as described in RFC1510 isn't a TypedData.  In fact, TypedData
was introduced in kerberos-revsions.  It would be useful to have a
separate typed hole that is not e-data, so we can disambiguate usages.

>> arguing over. Tom, comments?

John> If we are to move forward with the "2" proposal, then it does
John> make sense to place vno data in the outer encoding. I'm fine
John> with having the vno there - I'm still working on costing for the
John> "2" proposal.

It would make some amount of sense to do so, but then we'd have to
nail down semantics for how to handle a vno that you don't understand.

---Tom

---

From: Sam Hartman <[email-masked]>
Date: 24 Jan 2002 15:53:45 -0500

>> =20 e-data isn't a typed hole, that's the problem.

    John> Isn't the TypedData construct for e-data as described in the
    John> RFC and I-D a typed hole? There are some cases (legacy)
    John> where the TypedData is not used in e-data and those need to
    John> be accomodated. Win2000 and XP have a case where TypedData
    John> is not used.

Right.  typeddata is a hole, e-data is not.  We need to move away from
using raw e-data while still dealing with things that do use it.

Are you currently using typeddata for anything?

Do we have any cases where edata is currently being used without
typeddata, but we want to add additional information to the krb-error?

If the answer to the second question is no, one option we have is
simply to leave things as they are in the draft: new errors should use
edata with typeddata, while existing errors may not.

Another option we have regardless of the current state is to migrate
away from edata entirely.  We could add a new typed hole, possibly
mandating that in krb-error2 messages, edata must not be present.