Subject: Re: Clarification on KRB encrypted data checksums

From: Ken Raeburn <[email-masked]>
Date: 06 Feb 2002 15:49:18 -0500

"Louis LeVay"<[email-masked]> writes:
> However, when looking at the MIT code implementation (krb5-1.2.2 and
> earlier), it appears that the checksum (MD5 hash in this case) inludes the
> PAD (for the encryption block).

Yes, that's correct.

> Is this implementation incorrect (and would lead to inter-op problems for
> any Krb implementation that wasn't derived from an MIT code base), or should
> the spec be updated accordingly (which I believe is currently undergoing
> updates to the encryption/checksum section anyways)?

I'm updating the draft now.  It should be correct when -01 gets
submitted.

Thanks for catching it.

Ken

---

From: "Louis LeVay"<[email-masked]>
Date: Thu, 7 Feb 2002 17:46:42 -0500

> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]]

> > PAD (for the encryption block).

By "correct", I assume you are confirming my obsveration on the 
MIT code implementation...not necessarily that it is correct
(see below)

> I'm updating the draft now.  It should be correct when -01 gets

So the spec would be updated to reflect the MIT implementation
(i.e. checksum includes the PADDING)?

If not, then it seems in order to verify the checksum, the
receiver would have to do some partial ASN decoding of the msg (app data)
to determine the *real* length of the data using the implicit ASN encoded
length
(seems ok...since all use of EncryptedData in 1510bis has ASN.1 encoded
msg data)? ...other alternatives exist but would also need to be newly
defined

Thx
Louis