On Mon, Mar 24, 2008 at 5:49 PM, Paul B. Henson <[EMAIL PROTECTED]> wrote: > On Sat, 22 Mar 2008, [iso-8859-1] Roberto C. Sánchez wrote: > > > kadmin: ktadd host/phoenix.physik.unizh.ch > > kadmin: ktadd -e des-cbc-crc:normal nfs/phoenix.physik.unizh.ch > > > > That worked well for me. It lets me have DES only for NFS and 3DES for > > everything else. > > Is that for the client or the server? I tried having only the DES key for > the client: > > slot KVNO Principal > --------------------------------------------------------------------- > 3 3 nfs/[EMAIL PROTECTED] (DES cbc mode with CRC-32) > > With the same problem: > > rhel4 etc # klist -ec FILE:/tmp/krb5cc_machine_CSUPOMONA.EDU > Ticket cache: FILE:/tmp/krb5cc_machine_CSUPOMONA.EDU > Default principal: nfs/[EMAIL PROTECTED] > > Valid starting Expires Service principal > 03/24/08 10:33:02 03/25/08 10:33:02 krbtgt/[EMAIL PROTECTED] > renew until 04/07/08 10:33:02, Etype (skey, tkt): Triple DES cbc mode > with HMAC/sha1, Triple DES cbc mode with HMAC/sha1 > 03/24/08 10:33:37 03/25/08 10:33:02 nfs/[EMAIL PROTECTED] > renew until 04/07/08 10:33:02, Etype (skey, tkt): Triple DES cbc mode > with HMAC/sha1, Triple DES cbc mode with HMAC/sha1 > > > I know that you can *create* the NFS server principal with only a DES key, > which will result in all clients using DES. However, I have NFSv4 clients > that are actually capable of 3DES (for example, Solaris 10), and don't want > to cripple all NFS traffic either. > > I found a relevant post from three years ago: > > http://mailman.mit.edu/pipermail/kerberos/2005-April/007525.html > > > I guess my basic problem is that RHEL 4 is old and dusty :(, it actually > includes Kerberos 1.3. One of the reasons I hate running Red Hat -- so out > of date. Unfortunately, some proprietary commercial applications have a > dependency on it <sigh>... > > I suppose I'm just going to be stuck with some level of brokenness. Maybe > it is fixed in RHEL 5, I'll have to see if the commercial applications > support that yet.
Hi Paul, For a *Linux* NFS server, you currently *must* create its keytab with only a des-cbc-crc key. It doesn't matter if Solaris nfs clients can do better encryption to Solaris servers, the Linux server is limited to des. Creating the keytab in this way ensures that Linux or Solaris clients talking to the Linux server will only use des. For clients, as you've noted, if the Kerberos function is available (I think it was first put into MIT Kerberos 1.4), gssd limits the negotiated encryption type to des, only for NFS. Thus allowing other applications to use stronger enctypes as available. Without that functionality, your choices are (1) to limit other NFS servers to using only des, (i.e. creating your Solaris NFS server's keytab with only a des key, even though they may be able to do better), or (2) limiting all the Kerberos applications on your RHEL 4 Linux clients to des by using "default_tgs_enctypes = des-cbc-crc". RHEL 5 has MIT 1.6, so the problem shouldn't exist there. BTW, I'm finishing up Linux kernel patches to support the other enctypes, but as you noted, you won't be seeing those in a RHEL kernel for a while. K.C. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
