[23692] in Kerberos
Re: netapp, nfs, kerberos, and ldap
daemon@ATHENA.MIT.EDU (Kevin Coffman)
Mon Apr 11 10:12:33 2005
To: Mark Dieterich <mkd@cs.brown.edu>, coadyho@yahoo.com
In-reply-to: <iDO5e.645$n93.604@twister.nyc.rr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 11 Apr 2005 10:11:47 -0400
From: Kevin Coffman <kwc@citi.umich.edu>
Message-Id: <20050411141147.895AD1BACD@citi.umich.edu>
cc: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu
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@linux-nfs.org. Certainly problems with rpc.gssd
crashing should be addressed there or on the NFS list at
nfs@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@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
