netapp, nfs, kerberos, and ldap

[Jeffrey Altman]

Mark Dieterich wrote:
> Ahh...  So maybe this is my problem.  Should I be limiting the
> encryption type on my client side?  I'm positive that we have limited
> the nfs/host service principles to des-cbc-crc, but our client configs
> allow stronger encryption types.  The clients seem to be getting 3DES
> keys.  It's actually crashing the rpc.gssd daemon on the client and the
> only way we've been able to get everything to work is to have all of our
> keys be DES.

In other words, your Kerberos client libraries support 3DES but your
rpc.gssd daemon does not recognize the enctype and dies.  I bet a beer
that the daemon contains a fixed size array of enctype names for
debugging and the 3DES enctype value causes it to core dump.

Suggestion: fix the rpc.gssd.

Adding blanket restrictions on your client machines to force the use
of DES is going to hurt you in the long run.  What are you going to do
when breaking long term DES keys takes less than a month using standard
hardware?  When you remove DES support from your KDCs your clients
with hard coded restrictions to only use DES are going to become a
major support headache.

> I got a private email from someone else on the list that 3DES is a dead
> end and that the new standard for encryption will be AES.  Should I just
> bag getting 3DES running for now?  I know we can make things work if we
> just stick to DES.

AES is the new required enctype but it is not as widely supported as
either 3DES or RC4-HMAC.

> Thanks,
> 
> Mark
> 
> user wrote:
> 
>> Thank you, Jeffrey, for pointing it out.
>> Sorry, I didn't make it clear.
>>
>> It's on the client side, by restricting the requested
>> enctypes in the krb5.conf. In our case, the clients
>> don't support 3DES encryption.
>>
>> default_tkt_enctypes = des-cbc-crc
>> default_tgs_enctypes = des-cbc-crc

-- 
-----------------
This e-mail account is not read on a regular basis.