krsh/krlogin protocol

Nicolas Pouvesle 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 
a problem.
Maybe it is not a bug, maybe you do that for some compatibility reasons i 
don't know.

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 
undefined.
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 
now.

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,

Nicolas Pouvesle


More information about the krbdev mailing list