Hi,

from what I can gather, nfs-utils-1.2.3 introduced support for
encryption other than Single DES for NFSv4: Previously, gssd would
proactively limit Kerberos encryption types of session keys to
des-cbc-crc (and perhaps -md5 and -md4). So while the actual ticket
might be encrypted using something way stronger, the included session
key would only be Single DES.

Due to this self-limitation of the client, the server would never get
anything else than Single DES session keys and therefore needed no
mechanism of working around the problems caused by stronger session keys
with a kernel that does not support them.

Beginning with version 1.2.3 of nfs-utils, gssd does no longer limits
itself to Single DES. Instead, it detects the encryption types supported
by the *client's* kernel and limits the session key's encryption type to
those reported as supported. This, however, ignores the fact, that the
*server's* kernel might not support them. Since the userspace of the
server (svcgssd) does not check what its kernel supports and has no
mechanism of renegotiating with the client, it happily accepts stronger
encryption types and tries to push them into the kernel.

nfs-utils-1.2.4 includes a patch to svcgssd that uses
/proc/fs/nfsd/supported_encryption_types of newer kernels (2.6.35+ ?) to
determine the encryption types supported by the server's kernel and uses
subkey negotiation of current MIT Kerberos versions (1.9.1+) to
negotiate a possibly weaker encryption type with the client. While this
is a good solution for future enhancements and backwards compatibility
from now on it still leaves all the older installations with a problem.
RHEL5 for example only has MIT Kerberos 1.6 and will therefore most
likely never benefit from this fix.

A direct workaround is to set the following options in /etc/krb5.conf of
client and server:

[libdefaults]
default_tkt_enctypes = des-cbc-md5
permitted_enctypes = des-cbc-md5

, add des-cbc-md5 keys to the keytabs of both machines and allow Single
DES for both machines' principals on the KDC (MS AD 2008r2 in particular
wants it enabled explicitly). This however not only limits the
encryption types of session keys but all tickets as well and applies to
the whole machine not just the NFSv4 service. This has a needlessly high
security impact on both machines.

I quickly implemented a more self-contained fix that adds an option -l
to rpc.gssd that effectively reverts it to legacy behaviour: It ignores
its local kernel's capabilities and uses just Single DES. This option
could be set in e.g. /etc/sysconfig/nfs:GSSDARGS on all RHEL6 clients
that need to work with RHEL5 servers. It could possibly be enhanced to
be configurable on a per-machine basis. Inclusion of this or a similar
patch would be greatly appreciated.

Obviously this is just a proof-of-concept and still needs some
polishing. I was just wondering if my reasoning is sound and the
solution acceptable.

Thanks in advance,
-- 
Michael Weiser                science + computing ag
Senior Systems Engineer       Geschaeftsstelle Duesseldorf
                              Martinstrasse 47-55, Haus A
phone: +49 211 302 708 32     D-40223 Duesseldorf
fax:   +49 211 302 708 50     www.science-computing.de
-- 
Vorstandsvorsitzender/Chairman of the board of management:
Gerd-Lothar Leonhart
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Michael Heinrichs, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Philippe Miltin
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196