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

[Michael Weiser <M.Weiser@science-computing.de>]

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