nico.pou at fnac.net
Tue Sep 2 11:03:48 EDT 2003
> I can't imagine a legal problem; the MIT code is distributed under a
> GPL-compatible license, so even if you did use our code, you could
> still merge the patch into GNU Inetutils.
Thanks for your answer.
> Make sure you have all the cases covered: there is the old kcmd 0.1
> protocol, and the new protocol uses different key usages based on
> which enctype is used. Test with aes, 3des, rc4 and des to cover all
> the bases.
I was fixing my patches to allow 3des (only des-md4/5 was working) and i found
Maybe it is not a bug, maybe you do that for some compatibility reasons i
When rshd/rlogind (and telnet too i think) call the function
krb5_verify_checksum (in lib/crypto/old_api_glue.c) key params are just key
value and key length. A krb5_keyblock is created but the key enctype is
So if the original checksum type was for example sha1-hmac (like it is done in
shishi) the function will failed with bad_enc_type (in a sub call it looks if
enctype is ok, but like i said it was not initialised so in fact random).
Like in your code the checksum type is always to RSA-MD5 this function won't
failed, but for some other types it will.
I've added a fix in my patch to use always RSA-MD5 cksumtypes and it works
But i've patched your function to use full key as param and to call
verify_checksum with KRB5_KEYUSAGE_AP_REQ_AUTH_CKSUM keyusage and all seem to
work too (with an sha1-hmac cksum type).
So i just wanted to know if it is a bug, or if i should always use RSA-MD5
cksum type for a compatibility reason ?
Bye and thanks,
More information about the krbdev