netapp, nfs, kerberos, and ldap

[Kevin Coffman]

I'll assume we are dealing with a Linux NFS client here.  The problem 
is that the Linux kernel code currently (still) only supports 
des-cbc-crc.  However, if the nfs service principal is set up correctly 
(with only a des key), there should be no need to restrict the enctypes 
in krb5.conf.  Problems with the Linux nfs/krb5 implementation should 
be addressed to nfsv4 at linux-nfs.org.  Certainly problems with rpc.gssd 
crashing should be addressed there or on the NFS list at 
nfs at lists.sourceforge.net.

If you have mit krb5 1.4, then the following patch to the gssd code 
should properly limit the client negotiation to des-cbc-crc.


--- nfs-utils-1.0.7/utils/gssd/krb5_util.c~limit_to_supported_enctyps   
2005-04-11 09:55:16.677777000 -0400
+++ nfs-utils-1.0.7-kwc/utils/gssd/krb5_util.c  2005-04-11 
09:56:17.798026000 -0400
@@ -270,11 +270,7 @@ limit_krb5_enctypes(struct rpc_gss_sec *
 {
        u_int maj_stat, min_stat;
        gss_cred_id_t credh;
-/*     krb5_enctype enctypes[] = {ENCTYPE_DES3_CBC_SHA1};
-                                  ENCTYPE_ARCFOUR_HMAC, */
-       krb5_enctype enctypes[] = {ENCTYPE_DES3_CBC_SHA1,
-                                  ENCTYPE_DES_CBC_MD5,
-                                  ENCTYPE_DES_CBC_CRC};
+       krb5_enctype enctypes[] = { ENCTYPE_DES_CBC_CRC };
        int num_enctypes = sizeof(enctypes) / sizeof(enctypes[0]);
 
        maj_stat = gss_acquire_cred(&min_stat, NULL, 0,

_


> 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.
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos