Checksum (Re: KINK issue list)

"KAMADA Ken'ichi" <[email protected]> Thu, 27 Jan 2005 17:16:45 +0900
Newsgroups gmane.ietf.kink
Message-ID <20050127171645FM%[email protected]>
At Thu, 20 Jan 2005 11:04:48 +0900,
"KAMADA Ken'ichi" <[email protected]> wrote:
> 
> [**] 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)

With regard to these three issues, I'd propose using HMAC as a KINK
checksum.
According to kcrypto, each etype based on simplified profile and
etype based on 3DES has a HMAC as its attribute.  Let's use it as is.
DES-based etypes (des-cbc-md5, des-cbc-md4, and des-cbc-crc) have
no HMAC associated with them, so use HMAC-MD5.

My main concern with this proposal is whether all future etypes
will be based on simplified profile (have HMAC, I mean) or not.

-- 
KAMADA Ken'ichi <[email protected]>