NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

[Michael Weiser]

[-- Attachment #1: Type: text/plain, Size: 3713 bytes --]

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

[-- Attachment #2: 0001-Add-l-option-to-gssd-to-force-legacy-behaviour.patch --]
[-- Type: text/x-diff, Size: 2723 bytes --]

>From bd051cd3cc50d8d4695693c8f2d8cf78935c5711 Mon Sep 17 00:00:00 2001
From: Michael Weiser <weiser@science-computing.de>
Date: Mon, 12 Mar 2012 20:43:36 +0100
Subject: [PATCH] Add -l option to gssd to force legacy behaviour

A new option -l forces gssd to ignore its kernel's crypto capabilities
and use just the Single DES legacy encryption types to be compatible
with old servers without re-negotiation functionality.
---
 utils/gssd/gssd.c      |   12 +++++++++++-
 utils/gssd/krb5_util.c |    6 +++++-
 utils/gssd/krb5_util.h |    1 +
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/utils/gssd/gssd.c b/utils/gssd/gssd.c
index ccadb07..fff9d21 100644
--- a/utils/gssd/gssd.c
+++ b/utils/gssd/gssd.c
@@ -100,9 +100,14 @@ main(int argc, char *argv[])
 	int i;
 	extern char *optarg;
 	char *progname;
+#ifdef HAVE_SET_ALLOWABLE_ENCTYPES
+ 	const char *opts = "fvrmnMp:k:d:t:R:l";
+#else
+ 	const char *opts = "fvrmnMp:k:d:t:R";
+#endif
 
 	memset(ccachesearch, 0, sizeof(ccachesearch));
-	while ((opt = getopt(argc, argv, "fvrmnMp:k:d:t:R:")) != -1) {
+	while ((opt = getopt(argc, argv, opts)) != -1) {
 		switch (opt) {
 			case 'f':
 				fg = 1;
@@ -143,6 +148,11 @@ main(int argc, char *argv[])
 			case 'R':
 				preferred_realm = strdup(optarg);
 				break;
+#ifdef HAVE_SET_ALLOWABLE_ENCTYPES
+			case 'l':
+				limit_to_legacy_enctypes = 1;
+				break;
+#endif
 			default:
 				usage(argv[0]);
 				break;
diff --git a/utils/gssd/krb5_util.c b/utils/gssd/krb5_util.c
index 4b13fa1..887d118 100644
--- a/utils/gssd/krb5_util.c
+++ b/utils/gssd/krb5_util.c
@@ -129,6 +129,10 @@
 /* Global list of principals/cache file names for machine credentials */
 struct gssd_k5_kt_princ *gssd_k5_kt_princ_list = NULL;
 
+#ifdef HAVE_SET_ALLOWABLE_ENCTYPES
+int limit_to_legacy_enctypes = 0;
+#endif
+
 /*==========================*/
 /*===  Internal routines ===*/
 /*==========================*/
@@ -1342,7 +1346,7 @@ limit_krb5_enctypes(struct rpc_gss_sec *sec)
 	 * If we failed for any reason to produce global
 	 * list of supported enctypes, use local default here.
 	 */
-	if (krb5_enctypes == NULL)
+	if (krb5_enctypes == NULL || limit_to_legacy_enctypes)
 		maj_stat = gss_set_allowable_enctypes(&min_stat, credh,
 					&krb5oid, num_enctypes, enctypes);
 	else
diff --git a/utils/gssd/krb5_util.h b/utils/gssd/krb5_util.h
index b42b91e..cd6e107 100644
--- a/utils/gssd/krb5_util.h
+++ b/utils/gssd/krb5_util.h
@@ -36,6 +36,7 @@ char *gssd_k5_err_msg(krb5_context context, krb5_error_code code);
 void gssd_k5_get_default_realm(char **def_realm);
 
 #ifdef HAVE_SET_ALLOWABLE_ENCTYPES
+extern int limit_to_legacy_enctypes;
 int limit_krb5_enctypes(struct rpc_gss_sec *sec);
 #endif
 
-- 
1.7.3.4

Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

[Jim Rees]

Michael Weiser wrote:

  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.

Could this go in an appdefaults clause instead?

My guess is not.  I remember having to add allow_weak_crypto to libdefaults
instead of appdefaults.  But I thought I'd ask.

If not, a command line argument to gssd seems reasonable.

Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

[Kevin Coffman]

On Mon, Mar 12, 2012 at 4:02 PM, Michael Weiser
<M.Weiser@science-computing.de> wrote:
> 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,

To summarize, the base issue was not with gssd/svcgssd.  It was a
change in the Kerberos library code (if I recall correctly, in 1.7 or
1.8??) which ignores the limited enctypes in the server's keytab, and
instead uses the Kerberos library's capabilities to assert a subkey.

A proper fix needs to be on the server.  (Remember that non-Linux
clients may be trying to use that RHEL5 server, and have no such
mechanism to limit the requested enctypes.)

AFAIK, the only way to properly "fix" the issue is at the server by
adding "permitted_enctypes = des-cbc-md5" in krb5.conf.  This does
have the downside of limiting all services to DES, as you've stated.

I don't know if patches for Kerberos and nfs-utils could be pulled up
to RHEL5.  IMHO, that would be the ideal solution.

K.C.

Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

[Michael Weiser]

Hello Kevin,

On Mon, March 12, 2012 22:10, Kevin Coffman wrote:

> To summarize, the base issue was not with gssd/svcgssd.  It was a
> change in the Kerberos library code (if I recall correctly, in 1.7 or
> 1.8??) which ignores the limited enctypes in the server's keytab, and
> instead uses the Kerberos library's capabilities to assert a subkey.

Are you asking or telling?

>From my understanding up until RFC 4537 (Kerberos Cryptosystem Negotiation
Extension - which I hadn't heard of up until the day before yesterday), a
kerberised service had no mechanism to negotiate a ticket or session key
enctype with the client. This limitation is inherent to the Kerberos
protocol since the KDC at the time of creating both has no way of asking
the service which encryption types it currently supports. Instead, when
adding the service to the realm, a set of keys is put on the KDC and into
the service's keytab, thus only indirectly telling both, what enctypes the
service supports.

This seems to be exactly what the RFC's introduction
(http://tools.ietf.org/html/rfc4537#section-1) explains, although it
focusses on negotiating *stronger* encryption than what the KDC believes
the service supports.

So the proper workaround would be on the KDC by disabling all encryption
types but Single DES for the service's principal. Since this is somewhat
cumbersome in AD I instead just limited the client using the
default_tkt_enctypes and permitted_enctypes options.

The main problem I have with that, is that this degrades the encryption
type of the tickets as well. I know of no option to tell an MIT or AD KDC
to just limit the session key enctype to Single DES but encrypt the ticket
with AES256. So to keep my NFSv4 setup working with the newer version of
nfs-utils I actually have to make it even less secure.

Another possible workaround would be just setting permitted_enctypes =
des-cbc-md5 on the client and with perhaps a custom krb5.conf just for
nfs-utils. But in my tests, setting just permitted_enctypes and no
default_tkt_enctypes had no effect. This might be some AD speciality,
though, that I haven't tracked down yet.

> A proper fix needs to be on the server.  (Remember that non-Linux
> clients may be trying to use that RHEL5 server, and have no such
> mechanism to limit the requested enctypes.)

I would agree, if it could be done without subkey negotiation. Please tell
me, I'm wrong.

> AFAIK, the only way to properly "fix" the issue is at the server by
> adding "permitted_enctypes = des-cbc-md5" in krb5.conf.  This does
> have the downside of limiting all services to DES, as you've stated.

Because the server has no way of telling the client of this limitation,
the client will still obtain e.g. an arcfour ticket with arcfour session
key inside and present it to the server. Instead of the kernel saying
"gss_kerberos_mech: unsupported algorithm 23" svcgssd will say "Encryption
type not permitted" (or suchlike). The mount will still fail. Or not? It's
my experience so far, at least, and corresponds to my knowledge of how
Kerberos works.

> I don't know if patches for Kerberos and nfs-utils could be pulled up
> to RHEL5.  IMHO, that would be the ideal solution.

Yeah, that would be great. But I suspect, RFC4537-support from
mit-krb5-1.9 is somewhat more than a houndret lines of code and not very
backport-friendly. Also, this would need to be done in every Linux
distribution for all sorts of combinations of nfs-utils and mit-krb5. A
nice self-contained patch to nfs-utils or even just some
krb5.conf-[appdefaults]-magic seems a lot more friendly to me.

I wonder whether the client could securely apply a heuristic encryption
type detection: First it would try the strongest available encryption
type. If that didn't work, it'd try the next and so on down to Single DES
(if permitted in /etc/krb5.conf). But apart from the performance impact I
see the problem of an attacker interfering with the first few packets of a
mount to degrade authentication and encryption of a connection from aes256
to des-cbc-crc.

Thanks,
Micha
-- 
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

Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

[Kevin Coffman]

On Mon, Mar 12, 2012 at 5:57 PM, Michael Weiser
<M.Weiser@science-computing.de> wrote:
> Hello Kevin,
>
> On Mon, March 12, 2012 22:10, Kevin Coffman wrote:
>
>> To summarize, the base issue was not with gssd/svcgssd.  It was a
>> change in the Kerberos library code (if I recall correctly, in 1.7 or
>> 1.8??) which ignores the limited enctypes in the server's keytab, and
>> instead uses the Kerberos library's capabilities to assert a subkey.
>
> Are you asking or telling?

I'm telling about what happened.  I don't recall what version the
change was introduced.

> From my understanding up until RFC 4537 (Kerberos Cryptosystem Negotiation
> Extension - which I hadn't heard of up until the day before yesterday), a
> kerberised service had no mechanism to negotiate a ticket or session key
> enctype with the client. This limitation is inherent to the Kerberos
> protocol since the KDC at the time of creating both has no way of asking
> the service which encryption types it currently supports. Instead, when
> adding the service to the realm, a set of keys is put on the KDC and into
> the service's keytab, thus only indirectly telling both, what enctypes the
> service supports.

Prior to the change, the KDC knew what enctypes were in the service's
keytab and would limit the enctypes negotiated for the service.  After
the change, the service asserts enctypes based on the Kerberos
library's capabilities, not on what the service can actually handle.

> This seems to be exactly what the RFC's introduction
> (http://tools.ietf.org/html/rfc4537#section-1) explains, although it
> focusses on negotiating *stronger* encryption than what the KDC believes
> the service supports.
>
> So the proper workaround would be on the KDC by disabling all encryption
> types but Single DES for the service's principal. Since this is somewhat
> cumbersome in AD I instead just limited the client using the
> default_tkt_enctypes and permitted_enctypes options.
>
> The main problem I have with that, is that this degrades the encryption
> type of the tickets as well. I know of no option to tell an MIT or AD KDC
> to just limit the session key enctype to Single DES but encrypt the ticket
> with AES256. So to keep my NFSv4 setup working with the newer version of
> nfs-utils I actually have to make it even less secure.
>
> Another possible workaround would be just setting permitted_enctypes =
> des-cbc-md5 on the client and with perhaps a custom krb5.conf just for
> nfs-utils. But in my tests, setting just permitted_enctypes and no
> default_tkt_enctypes had no effect. This might be some AD speciality,
> though, that I haven't tracked down yet.
>
>> A proper fix needs to be on the server.  (Remember that non-Linux
>> clients may be trying to use that RHEL5 server, and have no such
>> mechanism to limit the requested enctypes.)
>
> I would agree, if it could be done without subkey negotiation. Please tell
> me, I'm wrong.
>
>> AFAIK, the only way to properly "fix" the issue is at the server by
>> adding "permitted_enctypes = des-cbc-md5" in krb5.conf.  This does
>> have the downside of limiting all services to DES, as you've stated.
>
> Because the server has no way of telling the client of this limitation,
> the client will still obtain e.g. an arcfour ticket with arcfour session
> key inside and present it to the server. Instead of the kernel saying
> "gss_kerberos_mech: unsupported algorithm 23" svcgssd will say "Encryption
> type not permitted" (or suchlike). The mount will still fail. Or not? It's
> my experience so far, at least, and corresponds to my knowledge of how
> Kerberos works.
>
>> I don't know if patches for Kerberos and nfs-utils could be pulled up
>> to RHEL5.  IMHO, that would be the ideal solution.
>
> Yeah, that would be great. But I suspect, RFC4537-support from
> mit-krb5-1.9 is somewhat more than a houndret lines of code and not very
> backport-friendly. Also, this would need to be done in every Linux
> distribution for all sorts of combinations of nfs-utils and mit-krb5. A
> nice self-contained patch to nfs-utils or even just some
> krb5.conf-[appdefaults]-magic seems a lot more friendly to me.

The Kerberos changes to allow the server side to limit the the
negotiated enctypes are not that extensive.  The nfs-utils changes may
be more than they are willing to include.

> I wonder whether the client could securely apply a heuristic encryption
> type detection: First it would try the strongest available encryption
> type. If that didn't work, it'd try the next and so on down to Single DES
> (if permitted in /etc/krb5.conf). But apart from the performance impact I
> see the problem of an attacker interfering with the first few packets of a
> mount to degrade authentication and encryption of a connection from aes256
> to des-cbc-crc.
>
> Thanks,
> Micha

I don't object to your change, but will assert that your suggested
solution does not handle non-Linux clients attempting to use the RHEL5
server.

K.C.

Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

[Michael Weiser]

Hello Kevin,

On Tue, Mar 13, 2012 at 09:51:46AM -0400, Kevin Coffman wrote:

> >> To summarize, the base issue was not with gssd/svcgssd.  It was a
> >> change in the Kerberos library code (if I recall correctly, in 1.7 or
> >> 1.8??) which ignores the limited enctypes in the server's keytab, and
> >> instead uses the Kerberos library's capabilities to assert a subkey.
> > Are you asking or telling?
> I'm telling about what happened.  I don't recall what version the
> change was introduced.

> > From my understanding up until RFC 4537 (Kerberos Cryptosystem Negotiation
> > Extension - which I hadn't heard of up until the day before yesterday), a
> > kerberised service had no mechanism to negotiate a ticket or session key
> > enctype with the client. This limitation is inherent to the Kerberos
> > protocol since the KDC at the time of creating both has no way of asking
> > the service which encryption types it currently supports. Instead, when
> > adding the service to the realm, a set of keys is put on the KDC and into
> > the service's keytab, thus only indirectly telling both, what enctypes the
> > service supports.
> Prior to the change, the KDC knew what enctypes were in the service's
> keytab and would limit the enctypes negotiated for the service.  After
> the change, the service asserts enctypes based on the Kerberos
> library's capabilities, not on what the service can actually handle.

Do you mean the introduction of subkey negotiation on the client side
without support for limiting the enctypes on the server side which was
corrected by mit-krb5 1.9.1 and your commit
d6c1b35c6b40243bfd6fba2591c9f8f2653078c0 to nfs-utils?

Then I understand now, what you meant. With your fix, subkey negotiation
should indeed work nicely if I have at least MIT Kerberos 1.7 and
nfs-utils-1.2.3 on the client and MIT Kerberos 1.9.1 and nfs-utils-1.2.4
on the server. (It does however not do so with current Debian packages
that have both fixes backported to MIT Kerberos 1.8.3 and
nfs-utils-1.2.2, but that's a different story.)

Unfortunetely all this is not my actual problem: What I'm seeing is that
gssd of nfs-utils-1.2.3 no longer limits itself to Single DES session
keys causing grief for an svcgssd that runs on a kernel that doesn't
support anything other than Single DES. This is not due to subkey
negotiation because the server only has MIT Kerberos 1.6 and
nfs-utils-1.0.9 which don't even support it. It is also not due to a
change on the KDC: All clients have always had aes256 and arcfour keys
in their keytabs and as long as they have older versions of nfs-utils
they work just fine with them.

For this case I need to limit gssd to Single DES *for session keys only*
even though it wants to do more. Since subkey negotiation can't be used
since Kerberos and nfs-utils on the server are too old, I need to do it
on the client.

You are right: I could limit the encryption types on the KDC and in the
client's keytab to Single DES. The nfs-utils gssd has however for some
time been bright enough to get tickets with stronger encryption types
but only Single DES session keys inside. I'd like to preserve that
behaviour because I expect it has a noticeable security impact.

It also has an administrative impact: Nowadays, Active Directory needs a
change to the security policy to even hand out Single DES encrypted
tickets while it is perfectly happy to hand out arcfour tickets with
Single DES session keys inside (without a change to the policy). So
basically, the new behaviour of nfs-utils' gssd will cause grief for NFS
administrators in AD environments while it would continue to work with
only client-side changes if the old gssd behaviour could be forced
somehow. I expect it's the same with any newly set-up MIT or Heimdal KDC
that has Single DES disabled by default.

> I don't object to your change, but will assert that your suggested
> solution does not handle non-Linux clients attempting to use the RHEL5
> server.

As far as I can see, this has always been the case: A solaris client
presenting a RHEL5 server with an arcfour session key would not be able
to mount. So I guess for Solaris clients I'd already have limited
encryption types on the KDC to Single DES so that the Solaris client
only gets Single DES session keys *and tickets*. Or the Solaris client
has logic similar to what gssd used to do which limits the session key
type to Single DES. I'll ask a collegue who actually runs a Solaris box
to see what it's doing.

Thanks for your patience,
Micha
-- 
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

Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

[Kevin Coffman]

On Tue, Mar 13, 2012 at 10:42 AM, Michael Weiser
<M.Weiser@science-computing.de> wrote:
> Hello Kevin,
>
> On Tue, Mar 13, 2012 at 09:51:46AM -0400, Kevin Coffman wrote:
>
>> >> To summarize, the base issue was not with gssd/svcgssd.  It was a
>> >> change in the Kerberos library code (if I recall correctly, in 1.7 or
>> >> 1.8??) which ignores the limited enctypes in the server's keytab, and
>> >> instead uses the Kerberos library's capabilities to assert a subkey.
>> > Are you asking or telling?
>> I'm telling about what happened.  I don't recall what version the
>> change was introduced.
>
>> > From my understanding up until RFC 4537 (Kerberos Cryptosystem Negotiation
>> > Extension - which I hadn't heard of up until the day before yesterday), a
>> > kerberised service had no mechanism to negotiate a ticket or session key
>> > enctype with the client. This limitation is inherent to the Kerberos
>> > protocol since the KDC at the time of creating both has no way of asking
>> > the service which encryption types it currently supports. Instead, when
>> > adding the service to the realm, a set of keys is put on the KDC and into
>> > the service's keytab, thus only indirectly telling both, what enctypes the
>> > service supports.
>> Prior to the change, the KDC knew what enctypes were in the service's
>> keytab and would limit the enctypes negotiated for the service.  After
>> the change, the service asserts enctypes based on the Kerberos
>> library's capabilities, not on what the service can actually handle.
>
> Do you mean the introduction of subkey negotiation on the client side
> without support for limiting the enctypes on the server side which was
> corrected by mit-krb5 1.9.1 and your commit
> d6c1b35c6b40243bfd6fba2591c9f8f2653078c0 to nfs-utils?

Hi Michael,

My understanding of the subkey negotiation is that the subkey is
asserted by the server, not the client.  If the client says it only
supports DES, then that will indeed limit what subkey the server's
Kerberos library will assert.

> Then I understand now, what you meant. With your fix, subkey negotiation
> should indeed work nicely if I have at least MIT Kerberos 1.7 and
> nfs-utils-1.2.3 on the client and MIT Kerberos 1.9.1 and nfs-utils-1.2.4
> on the server. (It does however not do so with current Debian packages
> that have both fixes backported to MIT Kerberos 1.8.3 and
> nfs-utils-1.2.2, but that's a different story.)
>
> Unfortunetely all this is not my actual problem: What I'm seeing is that
> gssd of nfs-utils-1.2.3 no longer limits itself to Single DES session
> keys causing grief for an svcgssd that runs on a kernel that doesn't
> support anything other than Single DES. This is not due to subkey
> negotiation because the server only has MIT Kerberos 1.6 and
> nfs-utils-1.0.9 which don't even support it. It is also not due to a
> change on the KDC: All clients have always had aes256 and arcfour keys
> in their keytabs and as long as they have older versions of nfs-utils
> they work just fine with them.
>
> For this case I need to limit gssd to Single DES *for session keys only*
> even though it wants to do more. Since subkey negotiation can't be used
> since Kerberos and nfs-utils on the server are too old, I need to do it
> on the client.
>
> You are right: I could limit the encryption types on the KDC and in the
> client's keytab to Single DES. The nfs-utils gssd has however for some
> time been bright enough to get tickets with stronger encryption types
> but only Single DES session keys inside. I'd like to preserve that
> behaviour because I expect it has a noticeable security impact.
>
> It also has an administrative impact: Nowadays, Active Directory needs a
> change to the security policy to even hand out Single DES encrypted
> tickets while it is perfectly happy to hand out arcfour tickets with
> Single DES session keys inside (without a change to the policy). So
> basically, the new behaviour of nfs-utils' gssd will cause grief for NFS
> administrators in AD environments while it would continue to work with
> only client-side changes if the old gssd behaviour could be forced
> somehow. I expect it's the same with any newly set-up MIT or Heimdal KDC
> that has Single DES disabled by default.
>
>> I don't object to your change, but will assert that your suggested
>> solution does not handle non-Linux clients attempting to use the RHEL5
>> server.
>
> As far as I can see, this has always been the case: A solaris client
> presenting a RHEL5 server with an arcfour session key would not be able
> to mount. So I guess for Solaris clients I'd already have limited
> encryption types on the KDC to Single DES so that the Solaris client
> only gets Single DES session keys *and tickets*. Or the Solaris client
> has logic similar to what gssd used to do which limits the session key
> type to Single DES. I'll ask a collegue who actually runs a Solaris box
> to see what it's doing.
>
> Thanks for your patience,
> Micha

The way things should work is that the client limits what enctypes it
negotiates based on the enctypes it can handle.  The server does the
same.

Before subkeys, the way to limit the enctypes on the server was to
issue the keytab with only the enctypes supported.  The KDC knew what
types were included in the server's keytab and issued the ticket with
a session key with that limitation in mind.  The extra code to limit
enctypes was added to the client because it had no such mechanism.

After subkeys, the server's keytab enctypes are still honored by the
KDC, however the server's Kerberos libraries assert a subkey based on
the enctypes supported by the libraries, ignoring the enctypes in the
keytab.  That required the additional support to limit the enctypes on
the server side as well.

It sounds like you are saying that your RHEL5 NFS server has a keytab
with more than a DES key.  If that is true, I think that is the issue.
 Not with the clients.

K.C.

Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

[Michael Weiser]

Hi Kevin,

On Tue, Mar 13, 2012 at 02:53:46PM -0400, Kevin Coffman wrote:

> It sounds like you are saying that your RHEL5 NFS server has a keytab
> with more than a DES key.  If that is true, I think that is the issue.
>  Not with the clients.

Yes, this is what I've been talking about: I have only aes256-cts and
arcfour-hmac keys in the keytabs of client and server:

[root@rhel5s1 etc]# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 nfs/rhel5s1.mydomain.example@MYDOMAIN.EXAMPLE (AES-256 CTS mode with 96-bit SHA-1 HMAC) 
   2 nfs/rhel5s1.mydomain.example@MYDOMAIN.EXAMPLE (ArcFour with HMAC/md5) 

and no configuration in /etc/krb5.conf whatsoever:

[root@rhel5s1 ~]# cat /etc/krb5.conf 
[libdefaults]
 default_realm = MYDOMAIN.EXAMPLE

With this configuration the mount works just fine (in this example the
server is its own client):

[root@rhel5s1 ~]# mount -t nfs4 -o sec=krb5 rhel5s1:/ /mnt/

gssd gets the following tickets (I had to disable a patch in RHEL5's
nfs-utils and recompile to get the ticket cache file in /tmp because
they've patched it to keep it in memory):

[root@rhel5s1 ~]# klist -e /tmp/krb5cc_machine_MYDOMAIN.EXAMPLE 
Ticket cache: FILE:/tmp/krb5cc_machine_MYDOMAIN.EXAMPLE
Default principal: nfs/rhel5s1.mydomain.example@MYDOMAIN.EXAMPLE

Valid starting     Expires            Service principal
03/14/12 13:53:32  03/14/12 23:53:32 krbtgt/MYDOMAIN.EXAMPLE@MYDOMAIN.EXAMPLE
        renew until 03/15/12 13:53:32,
	Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC 
03/14/12 13:53:32  03/14/12 23:53:32  nfs/rhel5s1.mydomain.example@
        renew until 03/15/12 13:53:32,
	Etype (skey, tkt): DES cbc mode with CRC-32, ArcFour with HMAC/md5 

So the client's ticket for the server is encrypted using arcfour-hmac
but the session key contained therein is only des-cbc-crc.

When accessing the mount, gssd gets the following ticket for the user:

[root@rhel5s1 ~]# su - user01
-sh-3.2$ kinit
Password for user01@MYDOMAIN.EXAMPLE: 
-sh-3.2$ ls /mnt
blub  projects
-sh-3.2$ klist -e
Ticket cache: FILE:/tmp/krb5cc_10100
Default principal: user01@MYDOMAIN.EXAMPLE

Valid starting     Expires            Service principal
03/14/12 13:57:25  03/14/12 23:57:27 krbtgt/MYDOMAIN.EXAMPLE@MYDOMAIN.EXAMPLE
        renew until 03/15/12 13:57:25,
	Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC 
03/14/12 13:57:34  03/14/12 23:57:27  nfs/rhel5s1.mydomain.example@
        renew until 03/15/12 13:57:25,
	Etype (skey, tkt): DES cbc mode with CRC-32, ArcFour with HMAC/md5 

This behaviour works so seamlessly, that I had assumed, it's intentional.
Are you telling me, that it is neither intended nor supported?

If so: Isn't this something we'd want to have? I accept that it's not
much use from an interoperability point of view but it sure simplifies
administration in a Linux-only environment. Doesn't this also have at
least some positive security impact? And as I've said, it greatly
simplifies Linux admins' life in an Active Directory 2008 R2+
environment where AD administrators will be very reluctant to change the
domain security policy for those obscure Linux boxes.

For completeness' sake: The RHEL6 client does not limit the session key
to Single DES and therefore the mount fails:

[root@rhel6 ~]# klist -e /tmp/krb5cc_machine_MYDOMAIN.EXAMPLE 
Ticket cache: FILE:/tmp/krb5cc_machine_MYDOMAIN.EXAMPLE
Default principal: nfs/rhel6.mydomain.example@MYDOMAIN.EXAMPLE

Valid starting     Expires            Service principal
03/14/12 14:00:19  03/15/12 00:00:20 krbtgt/MYDOMAIN.EXAMPLE@MYDOMAIN.EXAMPLE
        renew until 03/21/12 14:00:19,
	Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
03/14/12 14:00:20  03/15/12 00:00:20 nfs/rhel5s1.mydomain.example@MYDOMAIN.EXAMPLE
        renew until 03/21/12 14:00:19,
	Etype (skey, tkt): arcfour-hmac, arcfour-hmac 

Limiting the service account to Single DES on the KDC, putting just a
des-cbc-crc key in the server's keytab and adding allow_weak_crypto =
true to /etc/krb5.conf makes the mount work and yields the following
machine ticket cache on the client:

[root@rhel6 ~]# klist -e /tmp/krb5cc_machine_MYDOMAIN.EXAMPLE 
Ticket cache: FILE:/tmp/krb5cc_machine_MYDOMAIN.EXAMPLE
Default principal: nfs/rhel6.mydomain.example@MYDOMAIN.EXAMPLE

Valid starting     Expires            Service principal
03/14/12 14:04:48  03/15/12 00:04:48 krbtgt/MYDOMAIN.EXAMPLE@MYDOMAIN.EXAMPLE
        renew until 03/21/12 14:04:48,
	Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
03/14/12 14:04:48  03/15/12 00:04:48 nfs/rhel5s1.mydomain.example@MYDOMAIN.EXAMPLE
        renew until 03/21/12 14:04:48,
	Etype (skey, tkt): des-cbc-crc, des-cbc-md5 

For some funny reason, with my AD 2008R2 KDC, the ticket is encrypted
with des-cbc-md5 but accepted by the server anyway.

The user accessing the mount also gets just a des-cbc-crc/md5 ticket:

[user01@rhel6 ~]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: user01@MYDOMAIN.EXAMPLE

Valid starting     Expires            Service principal
03/14/12 14:08:48  03/15/12 00:08:50 krbtgt/MYDOMAIN.EXAMPLE@MYDOMAIN.EXAMPLE
        renew until 03/21/12 14:08:48,
	Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
03/14/12 14:08:52  03/15/12 00:08:50 nfs/rhel5s1.mydomain.example@MYDOMAIN.EXAMPLE
        renew until 03/21/12 14:08:48,
	Etype (skey, tkt): des-cbc-crc, des-cbc-md5 

With my legacy behaviour patch, RHEL6's gssd behaves like RHEL5's and
gets arcfour-encrypted tickets with des-cbc-crc session keys inside:

1. put stronger keys back into krb5.keytab of RHEL5 server
2. allow stronger encryption types for servers service account on KDC

[root@rhel6 ~]# rpc.gssd -l -vvv
[root@rhel6 ~]# mount -o vers=4,sec=krb5 rhel5s1:/ /mnt
[root@rhel6 ~]# klist -e /tmp/krb5cc_machine_MYDOMAIN.EXAMPLE 
Ticket cache: FILE:/tmp/krb5cc_machine_MYDOMAIN.EXAMPLE
Default principal: nfs/rhel6.mydomain.example@MYDOMAIN.EXAMPLE

Valid starting     Expires            Service principal
03/14/12 14:17:28  03/15/12 00:17:28 krbtgt/MYDOMAIN.EXAMPLE@MYDOMAIN.EXAMPLE
        renew until 03/21/12 14:17:28,
	Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
03/14/12 14:17:28  03/15/12 00:17:28 nfs/rhel5s1.mydomain.example@MYDOMAIN.EXAMPLE
        renew until 03/21/12 14:17:28,
	Etype (skey, tkt): des-cbc-crc, arcfour-hmac 

Same for a user:

[root@rhel6 ~]# su - user01
[user01@rhel6 ~]$ kinit
Password for user01@MYDOMAIN.EXAMPLE: 
[user01@rhel6 ~]$ ls /mnt
blub  projects
[user01@rhel6 ~]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: user01@MYDOMAIN.EXAMPLE

Valid starting     Expires            Service principal
03/14/12 14:18:52  03/15/12 00:18:53 krbtgt/MYDOMAIN.EXAMPLE@MYDOMAIN.EXAMPLE
        renew until 03/21/12 14:18:52,
	Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
03/14/12 14:18:56  03/15/12 00:18:53 nfs/rhel5s1.mydomain.example@MYDOMAIN.EXAMPLE
        renew until 03/21/12 14:18:52,
	Etype (skey, tkt): des-cbc-crc, arcfour-hmac 

Thanks,
-- 
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

Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

[Michael Weiser]

Hello Kevin,
Hello list,

On Wed, Mar 14, 2012 at 02:48:29PM +0100, Michael Weiser wrote:

> So the client's ticket for the server is encrypted using arcfour-hmac
> but the session key contained therein is only des-cbc-crc.

> This behaviour works so seamlessly, that I had assumed, it's intentional.
> Are you telling me, that it is neither intended nor supported?

> If so: Isn't this something we'd want to have? I accept that it's not
> much use from an interoperability point of view but it sure simplifies
> administration in a Linux-only environment. Doesn't this also have at
> least some positive security impact? And as I've said, it greatly
> simplifies Linux admins' life in an Active Directory 2008 R2+
> environment where AD administrators will be very reluctant to change the
> domain security policy for those obscure Linux boxes.

Any thoughts on this, anyone?

If nobody objects, I'd resubmit my patch to gssd with some cleanup and
documentation.

Thanks,
-- 
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

Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

[Steve Dickson]

Hello,

On 03/19/2012 09:00 AM, Michael Weiser wrote:
> Hello Kevin,
> Hello list,
> 
> On Wed, Mar 14, 2012 at 02:48:29PM +0100, Michael Weiser wrote:
> 
>> So the client's ticket for the server is encrypted using arcfour-hmac
>> but the session key contained therein is only des-cbc-crc.
> 
>> This behaviour works so seamlessly, that I had assumed, it's intentional.
>> Are you telling me, that it is neither intended nor supported?
> 
>> If so: Isn't this something we'd want to have? I accept that it's not
>> much use from an interoperability point of view but it sure simplifies
>> administration in a Linux-only environment. Doesn't this also have at
>> least some positive security impact? And as I've said, it greatly
>> simplifies Linux admins' life in an Active Directory 2008 R2+
>> environment where AD administrators will be very reluctant to change the
>> domain security policy for those obscure Linux boxes.
> 
> Any thoughts on this, anyone?
The fact you are making it simpler for admins is a good thing IMHO...

> 
> If nobody objects, I'd resubmit my patch to gssd with some cleanup and
> documentation.\
No, Please do...

steved.

Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

[Michael Weiser]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

Hi Steve,

On Tue, Mar 20, 2012 at 07:27:18AM -0400, Steve Dickson wrote:

> > If nobody objects, I'd resubmit my patch to gssd with some cleanup and
> > documentation.\
> No, Please do...

Here's the patch. Is there any special procedure to follow to get it
committed?

I just noticed that while the code bits are optional based on
HAVE_SET_ALLOWABLE_ENCTYPES, the man page part isn't. I've got no idea,
how to go about that.

Tanks,
-- 
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

[-- Attachment #2: 0001-Add-l-option-to-gssd-to-force-legacy-behaviour.patch --]
[-- Type: text/x-diff, Size: 5027 bytes --]

>From 6073594c72b7664b3c2534314fe6e83d30d7f78c Mon Sep 17 00:00:00 2001
From: Michael Weiser <weiser@science-computing.de>
Date: Tue, 20 Mar 2012 18:19:58 +0100
Subject: [PATCH] Add -l option to gssd to force legacy behaviour

Implement a new option -l to force gssd to ignore its kernel's crypto
capabilities and use just the Single DES legacy encryption types to be
compatible with old servers. This is only relevant if those servers have
strong keys in their keytab.
---
 utils/gssd/gssd.c      |   15 +++++++++++++--
 utils/gssd/gssd.man    |   22 +++++++++++++++++++++-
 utils/gssd/krb5_util.c |    6 +++++-
 utils/gssd/krb5_util.h |    1 +
 4 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/utils/gssd/gssd.c b/utils/gssd/gssd.c
index ccadb07..e873af1 100644
--- a/utils/gssd/gssd.c
+++ b/utils/gssd/gssd.c
@@ -55,6 +55,10 @@
 #include "gss_util.h"
 #include "krb5_util.h"
 
+#ifdef HAVE_SET_ALLOWABLE_ENCTYPES
+#define OPTS_ENCTYPES "l"
+#define USAGE_ENCTYPES " [-l]"
+#endif
 char pipefs_dir[PATH_MAX] = GSSD_PIPEFS_DIR;
 char keytabfile[PATH_MAX] = GSSD_DEFAULT_KEYTAB_FILE;
 char ccachedir[PATH_MAX] = GSSD_DEFAULT_CRED_DIR;
@@ -85,7 +89,8 @@ sig_hup(int signal)
 static void
 usage(char *progname)
 {
-	fprintf(stderr, "usage: %s [-f] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n",
+	fprintf(stderr, "usage: %s [-f]" USAGE_ENCTYPES
+			" [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n",
 		progname);
 	exit(1);
 }
@@ -102,7 +107,8 @@ main(int argc, char *argv[])
 	char *progname;
 
 	memset(ccachesearch, 0, sizeof(ccachesearch));
-	while ((opt = getopt(argc, argv, "fvrmnMp:k:d:t:R:")) != -1) {
+	while ((opt = getopt(argc, argv, "fvrmnMp:k:d:t:R"
+					OPTS_ENCTYPES)) != -1) {
 		switch (opt) {
 			case 'f':
 				fg = 1;
@@ -143,6 +149,11 @@ main(int argc, char *argv[])
 			case 'R':
 				preferred_realm = strdup(optarg);
 				break;
+#ifdef HAVE_SET_ALLOWABLE_ENCTYPES
+			case 'l':
+				limit_to_legacy_enctypes = 1;
+				break;
+#endif
 			default:
 				usage(argv[0]);
 				break;
diff --git a/utils/gssd/gssd.man b/utils/gssd/gssd.man
index 073379d..fd76bfe 100644
--- a/utils/gssd/gssd.man
+++ b/utils/gssd/gssd.man
@@ -6,7 +6,7 @@
 .SH NAME
 rpc.gssd \- rpcsec_gss daemon
 .SH SYNOPSIS
-.B "rpc.gssd [-f] [-n] [-k keytab] [-p pipefsdir] [-v] [-r] [-d ccachedir]"
+.B "rpc.gssd [-f] [-n] [-k keytab] [-l] [-p pipefsdir] [-v] [-r] [-d ccachedir]"
 .SH DESCRIPTION
 The rpcsec_gss protocol gives a means of using the gss-api generic security
 api to provide security for protocols using rpc (in particular, nfs).  Before
@@ -70,6 +70,26 @@ for "machine credentials" is now:
 If this search order does not use the correct key then provide a
 keytab file that contains only correct keys.
 .TP
+.B -l
+Tells
+.B rpc.gssd
+to limit session keys to Single DES even if the kernel supports stronger
+encryption types. Service ticket encryption is still governed by what
+the KDC believes the target server supports. This way the client can
+access a server that has strong keys in its keytab for ticket decryption
+but whose kernel only supports Single DES.
+.IP
+The alternative is to put only Single DES keys in the server's keytab
+and limit encryption types for its principal to Single DES on the KDC
+which will cause service tickets for this server to be encrypted using
+only Single DES and (as a side-effect) contain only Single DES session
+keys.
+.IP
+This legacy behaviour is only required for older servers
+(pre nfs-utils-1.2.4). If the server has a recent kernel, Kerberos
+implementation and nfs-utils it will work just fine with stronger
+encryption.
+.TP
 .B -p path
 Tells
 .B rpc.gssd
diff --git a/utils/gssd/krb5_util.c b/utils/gssd/krb5_util.c
index 4b13fa1..887d118 100644
--- a/utils/gssd/krb5_util.c
+++ b/utils/gssd/krb5_util.c
@@ -129,6 +129,10 @@
 /* Global list of principals/cache file names for machine credentials */
 struct gssd_k5_kt_princ *gssd_k5_kt_princ_list = NULL;
 
+#ifdef HAVE_SET_ALLOWABLE_ENCTYPES
+int limit_to_legacy_enctypes = 0;
+#endif
+
 /*==========================*/
 /*===  Internal routines ===*/
 /*==========================*/
@@ -1342,7 +1346,7 @@ limit_krb5_enctypes(struct rpc_gss_sec *sec)
 	 * If we failed for any reason to produce global
 	 * list of supported enctypes, use local default here.
 	 */
-	if (krb5_enctypes == NULL)
+	if (krb5_enctypes == NULL || limit_to_legacy_enctypes)
 		maj_stat = gss_set_allowable_enctypes(&min_stat, credh,
 					&krb5oid, num_enctypes, enctypes);
 	else
diff --git a/utils/gssd/krb5_util.h b/utils/gssd/krb5_util.h
index b42b91e..cd6e107 100644
--- a/utils/gssd/krb5_util.h
+++ b/utils/gssd/krb5_util.h
@@ -36,6 +36,7 @@ char *gssd_k5_err_msg(krb5_context context, krb5_error_code code);
 void gssd_k5_get_default_realm(char **def_realm);
 
 #ifdef HAVE_SET_ALLOWABLE_ENCTYPES
+extern int limit_to_legacy_enctypes;
 int limit_krb5_enctypes(struct rpc_gss_sec *sec);
 #endif
 
-- 
1.7.3.4

Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

[Michael Weiser]

Hi Steve,

On Tue, Mar 20, 2012 at 06:44:18PM +0100, Michael Weiser wrote:

> > > If nobody objects, I'd resubmit my patch to gssd with some cleanup and
> > > documentation.\
> > No, Please do...
> Here's the patch. Is there any special procedure to follow to get it
> committed?

How do I go about getting this committed?

> I just noticed that while the code bits are optional based on
> HAVE_SET_ALLOWABLE_ENCTYPES, the man page part isn't. I've got no idea,
> how to go about that.

Thanks,
-- 
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

Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

[Steve Dickson]

On 03/29/2012 10:02 AM, Michael Weiser wrote:
> Hi Steve,
> 
> On Tue, Mar 20, 2012 at 06:44:18PM +0100, Michael Weiser wrote:
> 
>>>> If nobody objects, I'd resubmit my patch to gssd with some cleanup and
>>>> documentation.\
>>> No, Please do...
>> Here's the patch. Is there any special procedure to follow to get it
>> committed?
> 
> How do I go about getting this committed?
My bad... I'm looking into this now....

> 
>> I just noticed that while the code bits are optional based on
>> HAVE_SET_ALLOWABLE_ENCTYPES, the man page part isn't. I've got no idea,
>> how to go about that.
I'm think we should remove all those defines and have the code enabled
by default. The main reason is defines like that just clutter up the 
code, plus there would be a needed for another configuration flag
which I think is a bit over kill... 

steved.

Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

[Michael Weiser]

[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]

Hi Steve,

On Thu, Apr 12, 2012 at 10:43:20AM -0400, Steve Dickson wrote:

> > How do I go about getting this committed?
> My bad... I'm looking into this now....

Thanks for getting back to me.

> >> I just noticed that while the code bits are optional based on
> >> HAVE_SET_ALLOWABLE_ENCTYPES, the man page part isn't. I've got no idea,
> >> how to go about that.
> I'm think we should remove all those defines and have the code enabled
> by default. The main reason is defines like that just clutter up the 
> code, plus there would be a needed for another configuration flag
> which I think is a bit over kill... 

Here it is. The whole HAVE_SET_ALLOWABLE_ENCTYPES logic is still in place
but my code now ignores it. So with a GSSAPI implementation that doesn't
support it, the -l switch will be accepted by gssd but silently do
nothing.

Thanks,
-- 
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

[-- Attachment #2: 0001-Add-l-option-to-gssd-to-force-legacy-behaviour.patch --]
[-- Type: text/x-diff, Size: 4556 bytes --]

>From 8ebaf42be06c87f52ca482dd954d4b710452e9e9 Mon Sep 17 00:00:00 2001
From: Michael Weiser <weiser@science-computing.de>
Date: Thu, 12 Apr 2012 17:44:12 +0200
Subject: [PATCH] Add -l option to gssd to force legacy behaviour

Implement a new option -l to force gssd to ignore its kernel's crypto
capabilities and use just the Single DES legacy encryption types to be
compatible with old servers. This is only relevant if those servers have
strong keys in their keytab.
---
 utils/gssd/gssd.c      |    7 +++++--
 utils/gssd/gssd.man    |   22 +++++++++++++++++++++-
 utils/gssd/krb5_util.c |    4 +++-
 utils/gssd/krb5_util.h |    1 +
 4 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/utils/gssd/gssd.c b/utils/gssd/gssd.c
index d53795e..d4c18a7 100644
--- a/utils/gssd/gssd.c
+++ b/utils/gssd/gssd.c
@@ -85,7 +85,7 @@ sig_hup(int signal)
 static void
 usage(char *progname)
 {
-	fprintf(stderr, "usage: %s [-f] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n",
+	fprintf(stderr, "usage: %s [-f] [-l] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n",
 		progname);
 	exit(1);
 }
@@ -102,7 +102,7 @@ main(int argc, char *argv[])
 	char *progname;
 
 	memset(ccachesearch, 0, sizeof(ccachesearch));
-	while ((opt = getopt(argc, argv, "fvrmnMp:k:d:t:R:")) != -1) {
+	while ((opt = getopt(argc, argv, "fvrmnMp:k:ld:t:R")) != -1) {
 		switch (opt) {
 			case 'f':
 				fg = 1;
@@ -143,6 +143,9 @@ main(int argc, char *argv[])
 			case 'R':
 				preferred_realm = strdup(optarg);
 				break;
+			case 'l':
+				limit_to_legacy_enctypes = 1;
+				break;
 			default:
 				usage(argv[0]);
 				break;
diff --git a/utils/gssd/gssd.man b/utils/gssd/gssd.man
index 073379d..fd76bfe 100644
--- a/utils/gssd/gssd.man
+++ b/utils/gssd/gssd.man
@@ -6,7 +6,7 @@
 .SH NAME
 rpc.gssd \- rpcsec_gss daemon
 .SH SYNOPSIS
-.B "rpc.gssd [-f] [-n] [-k keytab] [-p pipefsdir] [-v] [-r] [-d ccachedir]"
+.B "rpc.gssd [-f] [-n] [-k keytab] [-l] [-p pipefsdir] [-v] [-r] [-d ccachedir]"
 .SH DESCRIPTION
 The rpcsec_gss protocol gives a means of using the gss-api generic security
 api to provide security for protocols using rpc (in particular, nfs).  Before
@@ -70,6 +70,26 @@ for "machine credentials" is now:
 If this search order does not use the correct key then provide a
 keytab file that contains only correct keys.
 .TP
+.B -l
+Tells
+.B rpc.gssd
+to limit session keys to Single DES even if the kernel supports stronger
+encryption types. Service ticket encryption is still governed by what
+the KDC believes the target server supports. This way the client can
+access a server that has strong keys in its keytab for ticket decryption
+but whose kernel only supports Single DES.
+.IP
+The alternative is to put only Single DES keys in the server's keytab
+and limit encryption types for its principal to Single DES on the KDC
+which will cause service tickets for this server to be encrypted using
+only Single DES and (as a side-effect) contain only Single DES session
+keys.
+.IP
+This legacy behaviour is only required for older servers
+(pre nfs-utils-1.2.4). If the server has a recent kernel, Kerberos
+implementation and nfs-utils it will work just fine with stronger
+encryption.
+.TP
 .B -p path
 Tells
 .B rpc.gssd
diff --git a/utils/gssd/krb5_util.c b/utils/gssd/krb5_util.c
index 4b13fa1..c84d978 100644
--- a/utils/gssd/krb5_util.c
+++ b/utils/gssd/krb5_util.c
@@ -129,6 +129,8 @@
 /* Global list of principals/cache file names for machine credentials */
 struct gssd_k5_kt_princ *gssd_k5_kt_princ_list = NULL;
 
+int limit_to_legacy_enctypes = 0;
+
 /*==========================*/
 /*===  Internal routines ===*/
 /*==========================*/
@@ -1342,7 +1344,7 @@ limit_krb5_enctypes(struct rpc_gss_sec *sec)
 	 * If we failed for any reason to produce global
 	 * list of supported enctypes, use local default here.
 	 */
-	if (krb5_enctypes == NULL)
+	if (krb5_enctypes == NULL || limit_to_legacy_enctypes)
 		maj_stat = gss_set_allowable_enctypes(&min_stat, credh,
 					&krb5oid, num_enctypes, enctypes);
 	else
diff --git a/utils/gssd/krb5_util.h b/utils/gssd/krb5_util.h
index b42b91e..ddf00ca 100644
--- a/utils/gssd/krb5_util.h
+++ b/utils/gssd/krb5_util.h
@@ -38,6 +38,7 @@ void gssd_k5_get_default_realm(char **def_realm);
 #ifdef HAVE_SET_ALLOWABLE_ENCTYPES
 int limit_krb5_enctypes(struct rpc_gss_sec *sec);
 #endif
+extern int limit_to_legacy_enctypes;
 
 /*
  * Hide away some of the MIT vs. Heimdal differences
-- 
1.7.3.4

Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

[Steve Dickson]

On 04/12/2012 11:49 AM, Michael Weiser wrote:
> Hi Steve,
> 
> On Thu, Apr 12, 2012 at 10:43:20AM -0400, Steve Dickson wrote:
> 
>>> How do I go about getting this committed?
>> My bad... I'm looking into this now....
> 
> Thanks for getting back to me.
> 
>>>> I just noticed that while the code bits are optional based on
>>>> HAVE_SET_ALLOWABLE_ENCTYPES, the man page part isn't. I've got no idea,
>>>> how to go about that.
>> I'm think we should remove all those defines and have the code enabled
>> by default. The main reason is defines like that just clutter up the 
>> code, plus there would be a needed for another configuration flag
>> which I think is a bit over kill... 
> 
> Here it is. The whole HAVE_SET_ALLOWABLE_ENCTYPES logic is still in place
> but my code now ignores it. So with a GSSAPI implementation that doesn't
> support it, the -l switch will be accepted by gssd but silently do
> nothing.
Well after further review.... it appears remove moving those defines would
have a negative impact on backwards compatibility with older Kerberos 
libraries. 

So what I'm thinking of doing is error out if an admin tries to use the 
-l flag with incompatible  Kerberos libraries. I also made a note in
the man page. So how about something like this:


Author: Michael Weiser <weiser@science-computing.de>
Date:   Thu Apr 12 11:50:03 2012 -0400

    Add -l option to gssd to force legacy behaviour
    
    Implement a new option -l to force gssd to ignore its kernel's crypto
    capabilities and use just the Single DES legacy encryption types to be
    compatible with old servers. This is only relevant if those servers have
    strong keys in their keytab.
    
    Signed-off-by: Steve Dickson <steved@redhat.com>

diff --git a/utils/gssd/gssd.c b/utils/gssd/gssd.c
index d53795e..7825255 100644
--- a/utils/gssd/gssd.c
+++ b/utils/gssd/gssd.c
@@ -85,7 +85,7 @@ sig_hup(int signal)
 static void
 usage(char *progname)
 {
-	fprintf(stderr, "usage: %s [-f] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n",
+	fprintf(stderr, "usage: %s [-f] [-l] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n",
 		progname);
 	exit(1);
 }
@@ -102,7 +102,7 @@ main(int argc, char *argv[])
 	char *progname;
 
 	memset(ccachesearch, 0, sizeof(ccachesearch));
-	while ((opt = getopt(argc, argv, "fvrmnMp:k:d:t:R:")) != -1) {
+	while ((opt = getopt(argc, argv, "fvrlmnMp:k:d:t:R")) != -1) {
 		switch (opt) {
 			case 'f':
 				fg = 1;
@@ -143,6 +143,13 @@ main(int argc, char *argv[])
 			case 'R':
 				preferred_realm = strdup(optarg);
 				break;
+			case 'l':
+#ifdef HAVE_SET_ALLOWABLE_ENCTYPES
+				limit_to_legacy_enctypes = 1;
+#else 
+				errx(1, "Setting encryption type not support by Kerberos libraries.");
+#endif
+				break;
 			default:
 				usage(argv[0]);
 				break;
diff --git a/utils/gssd/gssd.man b/utils/gssd/gssd.man
index 073379d..d8138fa 100644
--- a/utils/gssd/gssd.man
+++ b/utils/gssd/gssd.man
@@ -6,7 +6,7 @@
 .SH NAME
 rpc.gssd \- rpcsec_gss daemon
 .SH SYNOPSIS
-.B "rpc.gssd [-f] [-n] [-k keytab] [-p pipefsdir] [-v] [-r] [-d ccachedir]"
+.B "rpc.gssd [-f] [-n] [-k keytab] [-l] [-p pipefsdir] [-v] [-r] [-d ccachedir]"
 .SH DESCRIPTION
 The rpcsec_gss protocol gives a means of using the gss-api generic security
 api to provide security for protocols using rpc (in particular, nfs).  Before
@@ -70,6 +70,30 @@ for "machine credentials" is now:
 If this search order does not use the correct key then provide a
 keytab file that contains only correct keys.
 .TP
+.B -l
+Tells
+.B rpc.gssd
+to limit session keys to Single DES even if the kernel supports stronger
+encryption types. Service ticket encryption is still governed by what
+the KDC believes the target server supports. This way the client can
+access a server that has strong keys in its keytab for ticket decryption
+but whose kernel only supports Single DES.
+.IP
+The alternative is to put only Single DES keys in the server's keytab
+and limit encryption types for its principal to Single DES on the KDC
+which will cause service tickets for this server to be encrypted using
+only Single DES and (as a side-effect) contain only Single DES session
+keys.
+.IP
+This legacy behaviour is only required for older servers
+(pre nfs-utils-1.2.4). If the server has a recent kernel, Kerberos
+implementation and nfs-utils it will work just fine with stronger
+encryption.
+.IP
+.B Note:
+This option is only available with Kerberos libraries that 
+support setable encryption types.
+.TP
 .B -p path
 Tells
 .B rpc.gssd
diff --git a/utils/gssd/krb5_util.c b/utils/gssd/krb5_util.c
index 4b13fa1..887d118 100644
--- a/utils/gssd/krb5_util.c
+++ b/utils/gssd/krb5_util.c
@@ -129,6 +129,10 @@
 /* Global list of principals/cache file names for machine credentials */
 struct gssd_k5_kt_princ *gssd_k5_kt_princ_list = NULL;
 
+#ifdef HAVE_SET_ALLOWABLE_ENCTYPES
+int limit_to_legacy_enctypes = 0;
+#endif
+
 /*==========================*/
 /*===  Internal routines ===*/
 /*==========================*/
@@ -1342,7 +1346,7 @@ limit_krb5_enctypes(struct rpc_gss_sec *sec)
 	 * If we failed for any reason to produce global
 	 * list of supported enctypes, use local default here.
 	 */
-	if (krb5_enctypes == NULL)
+	if (krb5_enctypes == NULL || limit_to_legacy_enctypes)
 		maj_stat = gss_set_allowable_enctypes(&min_stat, credh,
 					&krb5oid, num_enctypes, enctypes);
 	else
diff --git a/utils/gssd/krb5_util.h b/utils/gssd/krb5_util.h
index b42b91e..cd6e107 100644
--- a/utils/gssd/krb5_util.h
+++ b/utils/gssd/krb5_util.h
@@ -36,6 +36,7 @@ char *gssd_k5_err_msg(krb5_context context, krb5_error_code code);
 void gssd_k5_get_default_realm(char **def_realm);
 
 #ifdef HAVE_SET_ALLOWABLE_ENCTYPES
+extern int limit_to_legacy_enctypes;
 int limit_krb5_enctypes(struct rpc_gss_sec *sec);
 #endif
 

If this seems reasonable, would you mind giving it a test run to 
ensure I have not broken anything? tia..

steved.

Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

[Michael Weiser]

Hi Steve,

On Thu, Apr 12, 2012 at 12:02:19PM -0400, Steve Dickson wrote:

> > Here it is. The whole HAVE_SET_ALLOWABLE_ENCTYPES logic is still in place
> > but my code now ignores it. So with a GSSAPI implementation that doesn't
> > support it, the -l switch will be accepted by gssd but silently do
> > nothing.
> Well after further review.... it appears remove moving those defines would
> have a negative impact on backwards compatibility with older Kerberos 
> libraries. 

> So what I'm thinking of doing is error out if an admin tries to use the 
> -l flag with incompatible  Kerberos libraries. I also made a note in
> the man page. So how about something like this:

No arguments from me. Seems a great solution.

> If this seems reasonable, would you mind giving it a test run to 
> ensure I have not broken anything? tia..

I gave it a spin on my RHEL6 VM and everything still works.

Compiling with HAVE_SET_ALLOWABLE_ENCTYPES undefined produces a gssd
that bails as intended:

[root@rhel6 gssd]# ./gssd -vvv -f -l
gssd: Setting encryption type not support by Kerberos libraries.

Thanks,
-- 
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

Re: NFSv4 post-1.2.2 nfs-utils client fails to mount from pre-1.2.3 nfs-utils server

[Steve Dickson]

On 04/12/2012 12:02 PM, Steve Dickson wrote:
> 
> 
> On 04/12/2012 11:49 AM, Michael Weiser wrote:
>> Hi Steve,
>>
>> On Thu, Apr 12, 2012 at 10:43:20AM -0400, Steve Dickson wrote:
>>
>>>> How do I go about getting this committed?
>>> My bad... I'm looking into this now....
>>
>> Thanks for getting back to me.
>>
>>>>> I just noticed that while the code bits are optional based on
>>>>> HAVE_SET_ALLOWABLE_ENCTYPES, the man page part isn't. I've got no idea,
>>>>> how to go about that.
>>> I'm think we should remove all those defines and have the code enabled
>>> by default. The main reason is defines like that just clutter up the 
>>> code, plus there would be a needed for another configuration flag
>>> which I think is a bit over kill... 
>>
>> Here it is. The whole HAVE_SET_ALLOWABLE_ENCTYPES logic is still in place
>> but my code now ignores it. So with a GSSAPI implementation that doesn't
>> support it, the -l switch will be accepted by gssd but silently do
>> nothing.
> Well after further review.... it appears remove moving those defines would
> have a negative impact on backwards compatibility with older Kerberos 
> libraries. 
> 
> So what I'm thinking of doing is error out if an admin tries to use the 
> -l flag with incompatible  Kerberos libraries. I also made a note in
> the man page. So how about something like this:
> 
> 
> Author: Michael Weiser <weiser@science-computing.de>
> Date:   Thu Apr 12 11:50:03 2012 -0400
> 
>     Add -l option to gssd to force legacy behaviour
>     
>     Implement a new option -l to force gssd to ignore its kernel's crypto
>     capabilities and use just the Single DES legacy encryption types to be
>     compatible with old servers. This is only relevant if those servers have
>     strong keys in their keytab.
>     
>     Signed-off-by: Steve Dickson <steved@redhat.com>
Committed... 

steved.
> 
> diff --git a/utils/gssd/gssd.c b/utils/gssd/gssd.c
> index d53795e..7825255 100644
> --- a/utils/gssd/gssd.c
> +++ b/utils/gssd/gssd.c
> @@ -85,7 +85,7 @@ sig_hup(int signal)
>  static void
>  usage(char *progname)
>  {
> -	fprintf(stderr, "usage: %s [-f] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n",
> +	fprintf(stderr, "usage: %s [-f] [-l] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n",
>  		progname);
>  	exit(1);
>  }
> @@ -102,7 +102,7 @@ main(int argc, char *argv[])
>  	char *progname;
>  
>  	memset(ccachesearch, 0, sizeof(ccachesearch));
> -	while ((opt = getopt(argc, argv, "fvrmnMp:k:d:t:R:")) != -1) {
> +	while ((opt = getopt(argc, argv, "fvrlmnMp:k:d:t:R")) != -1) {
>  		switch (opt) {
>  			case 'f':
>  				fg = 1;
> @@ -143,6 +143,13 @@ main(int argc, char *argv[])
>  			case 'R':
>  				preferred_realm = strdup(optarg);
>  				break;
> +			case 'l':
> +#ifdef HAVE_SET_ALLOWABLE_ENCTYPES
> +				limit_to_legacy_enctypes = 1;
> +#else 
> +				errx(1, "Setting encryption type not support by Kerberos libraries.");
> +#endif
> +				break;
>  			default:
>  				usage(argv[0]);
>  				break;
> diff --git a/utils/gssd/gssd.man b/utils/gssd/gssd.man
> index 073379d..d8138fa 100644
> --- a/utils/gssd/gssd.man
> +++ b/utils/gssd/gssd.man
> @@ -6,7 +6,7 @@
>  .SH NAME
>  rpc.gssd \- rpcsec_gss daemon
>  .SH SYNOPSIS
> -.B "rpc.gssd [-f] [-n] [-k keytab] [-p pipefsdir] [-v] [-r] [-d ccachedir]"
> +.B "rpc.gssd [-f] [-n] [-k keytab] [-l] [-p pipefsdir] [-v] [-r] [-d ccachedir]"
>  .SH DESCRIPTION
>  The rpcsec_gss protocol gives a means of using the gss-api generic security
>  api to provide security for protocols using rpc (in particular, nfs).  Before
> @@ -70,6 +70,30 @@ for "machine credentials" is now:
>  If this search order does not use the correct key then provide a
>  keytab file that contains only correct keys.
>  .TP
> +.B -l
> +Tells
> +.B rpc.gssd
> +to limit session keys to Single DES even if the kernel supports stronger
> +encryption types. Service ticket encryption is still governed by what
> +the KDC believes the target server supports. This way the client can
> +access a server that has strong keys in its keytab for ticket decryption
> +but whose kernel only supports Single DES.
> +.IP
> +The alternative is to put only Single DES keys in the server's keytab
> +and limit encryption types for its principal to Single DES on the KDC
> +which will cause service tickets for this server to be encrypted using
> +only Single DES and (as a side-effect) contain only Single DES session
> +keys.
> +.IP
> +This legacy behaviour is only required for older servers
> +(pre nfs-utils-1.2.4). If the server has a recent kernel, Kerberos
> +implementation and nfs-utils it will work just fine with stronger
> +encryption.
> +.IP
> +.B Note:
> +This option is only available with Kerberos libraries that 
> +support setable encryption types.
> +.TP
>  .B -p path
>  Tells
>  .B rpc.gssd
> diff --git a/utils/gssd/krb5_util.c b/utils/gssd/krb5_util.c
> index 4b13fa1..887d118 100644
> --- a/utils/gssd/krb5_util.c
> +++ b/utils/gssd/krb5_util.c
> @@ -129,6 +129,10 @@
>  /* Global list of principals/cache file names for machine credentials */
>  struct gssd_k5_kt_princ *gssd_k5_kt_princ_list = NULL;
>  
> +#ifdef HAVE_SET_ALLOWABLE_ENCTYPES
> +int limit_to_legacy_enctypes = 0;
> +#endif
> +
>  /*==========================*/
>  /*===  Internal routines ===*/
>  /*==========================*/
> @@ -1342,7 +1346,7 @@ limit_krb5_enctypes(struct rpc_gss_sec *sec)
>  	 * If we failed for any reason to produce global
>  	 * list of supported enctypes, use local default here.
>  	 */
> -	if (krb5_enctypes == NULL)
> +	if (krb5_enctypes == NULL || limit_to_legacy_enctypes)
>  		maj_stat = gss_set_allowable_enctypes(&min_stat, credh,
>  					&krb5oid, num_enctypes, enctypes);
>  	else
> diff --git a/utils/gssd/krb5_util.h b/utils/gssd/krb5_util.h
> index b42b91e..cd6e107 100644
> --- a/utils/gssd/krb5_util.h
> +++ b/utils/gssd/krb5_util.h
> @@ -36,6 +36,7 @@ char *gssd_k5_err_msg(krb5_context context, krb5_error_code code);
>  void gssd_k5_get_default_realm(char **def_realm);
>  
>  #ifdef HAVE_SET_ALLOWABLE_ENCTYPES
> +extern int limit_to_legacy_enctypes;
>  int limit_krb5_enctypes(struct rpc_gss_sec *sec);
>  #endif
>  
> 
> If this seems reasonable, would you mind giving it a test run to 
> ensure I have not broken anything? tia..
> 
> steved.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html