Secure NFS under Red Hat Enterprise Linux 4

[Kevin Coffman]

On Mon, Mar 24, 2008 at 5:49 PM, Paul B. Henson <henson at acm.org> 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/rhel4.unx.csupomona.edu at CSUPOMONA.EDU (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/rhel4.unx.csupomona.edu at CSUPOMONA.EDU
>
>  Valid starting     Expires            Service principal
>  03/24/08 10:33:02  03/25/08 10:33:02  krbtgt/CSUPOMONA.EDU at CSUPOMONA.EDU
>         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/zfs1.unx.csupomona.edu at CSUPOMONA.EDU
>         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.