Re: KINK issue list

Hello,

I have read the mails and I think these issues could be closed.

Kamada-san described the checksum calculation and verification in
this mail.
http://www.vpnc.org/ietf-kink/mail-archive/msg00336.html

If KINK adopts this, check sum length in KINK header will be two
octets because kcrypto specifies that the output of get_mic is
no longer than 65535 octets in the section 4.

BTW, if there are no strong reason, I like to move the check sum
field from the header to the end of message, because we could
be easy to access KINK_AP_REQ/REP payload and forget it after
verification.

KAMADA Ken'ichi wrote:
> Here is a merged version of KINK issues expressed till now.
> If I missed some of them you noted, please let me know.
> 
> 

<snip>

> 
> 
> [*] CksumLen (section 5)
> 
> 	Diagram indicates one octet for cksumlen, but the text (and 
> 	kcrypto specifications) say it should be two.
> 
> 
> [**] etype does not directly indicate checksum type (section 5)
> 
> 	a key's encryption type does not directly indicate 
> 	a checksum type, it indicates an encryption(-with-integrity-protection) 
> 	scheme, which does include a required-to-implement checksum type
> 	(Ken Raeburn)
> 
> 
> [**] Kerberos allows variable length checksum (section 5)
> 
> 	I'd have to go back and check, but I don't think we require that 
> 	a given checksum type have a fixed output size, so "leave X amount of 
> 	space and fill it with zero for computing the checksum" is questionable 
> 	too.  (Ken Raeburn)
> 
> 
> [*] Kerberos checksum is not deterministic (section 5)
> 
> 	The Kink description of how to verify a checksum assumes that
> 	Kerberos checksums are deterministic; this is not strictly required.
> 	(Sam Hartman)
> 
> 	let kcrypto specify how 
> 	to verify a checksum, as they're not required to be deterministic, so 
> 	the "compute it again and compare" approach specified in section 5 is 
> 	wrong  (Ken Raeburn)
> 
> 	The spec should describe how to verify checksum as follows.
> 
> 	To verify the checksum, the checksum is saved, and the
> 	checksum field is zeroed out.  The resulting message and the saved
> 	checksum are passed to the verification function.  If the verification
> 	fails, the message MUST be dropped.
> 
> 

--
Kazunori Miyazawa