Skip to contentSkip to conversation

NFS4 des and weak crypto

DISCUSSION steve 4 participants 5 messages Feb 16, 2012 – Mar 1, 2012 1 message not in the archive

Subsystems (2)
lore
Share & tools
lore

steve

author
#0 lore raw

Hi
openSUSE 12.1

I'm trying to explain to our windows admin that modern nfs isn't restricted to DES.

Here is a Samba4 authenticated test setup.

I've removed he DES keys from the keytab on the nfs server:

klist -ke /etc/krb5.keytab
Keytab name: WRFILE:/etc/krb5.keytab
KVNO Principal
---- ---------
1 nfs/[email protected] (arcfour-hmac)
1 [email protected] (arcfour-hmac)

In /etc/krb5.conf, I comment out:
[libdefaults]
#allow_weak_crypto = true
It was never actually there. I've added it help my argument;) hh3 is the server, hh6 is the client.

On hh6, root issues:
mount -t nfs4 hh3:/foo /bar -o sec=krb5 rpc.gssd -fvvv throws a fit, the KDC responds with,

Kerberos: ENC-TS Pre-authentication succeeded -- [email protected] using arcfour-hmac-md5
Kerberos: AS-REQ authtime: 2012-02-06T19:44:47 starttime: unset endtime: 2012-02-07T05:44:47 renew till: 2012-02-07T19:44:47
Kerberos: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, des-cbc-crc, des-cbc-md5, des-cbc-md4, using arcfour-hmac-md5/arcfour-hmac-md5
Kerberos: Requested flags: renewable-ok
Kerberos: TGS-REQ [email protected] from ipv4:192.168.1.10:45421 for nfs/[email protected] [canonicalize, renewable]
Kerberos: TGS-REQ authtime: 2012-02-06T19:44:47 starttime: 2012-02-06T19:44:47 endtime: 2012-02-07T05:44:47 renew till: 20

we can logon and request files via the mount.

Questions
Does this procedure prove that nfs can use other than DES crypto? Is arcfour what an AD admin would consider strong encryption?

Thanks,
Steve

#1 lore raw
Quoted 38 lines · steve

Hi
openSUSE 12.1

I'm trying to explain to our windows admin that modern nfs isn't restricted to DES.

Here is a Samba4 authenticated test setup.

I've removed he DES keys from the keytab on the nfs server:

klist -ke /etc/krb5.keytab
Keytab name: WRFILE:/etc/krb5.keytab
KVNO Principal
---- ---------
  1 nfs/[email protected] (arcfour-hmac)
  1 [email protected] (arcfour-hmac)

In /etc/krb5.conf, I comment out:
[libdefaults]
#allow_weak_crypto = true
It was never actually there. I've added it help my argument;) hh3 is the server, hh6 is the client.

On hh6, root issues:
mount -t nfs4 hh3:/foo /bar -o sec=krb5 rpc.gssd -fvvv throws a fit, the KDC responds with,

Kerberos: ENC-TS Pre-authentication succeeded -- [email protected] using arcfour-hmac-md5
Kerberos: AS-REQ authtime: 2012-02-06T19:44:47 starttime: unset endtime:

2012-02-07T05:44:47 renew till: 2012-02-07T19:44:47

Kerberos: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, des-cbc-crc, des-cbc-md5, des-cbc-md4, using arcfour-hmac-md5/arcfour-hmac-md5
Kerberos: Requested flags: renewable-ok
Kerberos: TGS-REQ [email protected] from ipv4:192.168.1.10:45421 for nfs/[email protected] [canonicalize, renewable]
Kerberos: TGS-REQ authtime: 2012-02-06T19:44:47 starttime:

Quoted 7 lines
2012-02-06T19:44:47 endtime: 2012-02-07T05:44:47 renew till: 20

we can logon and request files via the mount.

Questions
Does this procedure prove that nfs can use other than DES crypto? Is arcfour what an AD admin would consider strong encryption?

Linux NFS clients and servers can use any of the crypto listed above in the "client supported enctypes". aes256-cts-hmac-sha1-96 is the strongest.

-->Andy

Quoted 8 lines

Thanks,
Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

#2 lore raw
Quoted 41 lines · Andy Adamson
Quoted 40 lines · steve

Hi
openSUSE 12.1

I'm trying to explain to our windows admin that modern nfs isn't restricted to DES.

Here is a Samba4 authenticated test setup.

I've removed he DES keys from the keytab on the nfs server:

klist -ke /etc/krb5.keytab
Keytab name: WRFILE:/etc/krb5.keytab
KVNO Principal
---- ---------
  1 nfs/[email protected] (arcfour-hmac)
  1 [email protected] (arcfour-hmac)

In /etc/krb5.conf, I comment out:
[libdefaults]
#allow_weak_crypto = true
It was never actually there. I've added it help my argument;) hh3 is the server, hh6 is the client.

On hh6, root issues:
mount -t nfs4 hh3:/foo /bar -o sec=krb5 rpc.gssd -fvvv throws a fit, the KDC responds with,

Kerberos: ENC-TS Pre-authentication succeeded -- [email protected] using arcfour-hmac-md5
Kerberos: AS-REQ authtime: 2012-02-06T19:44:47 starttime: unset endtime:

2012-02-07T05:44:47 renew till: 2012-02-07T19:44:47

Kerberos: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, des-cbc-crc, des-cbc-md5, des-cbc-md4, using arcfour-hmac-md5/arcfour-hmac-md5
Kerberos: Requested flags: renewable-ok
Kerberos: TGS-REQ [email protected] from ipv4:192.168.1.10:45421 for nfs/[email protected] [canonicalize, renewable]
Kerberos: TGS-REQ authtime: 2012-02-06T19:44:47 starttime:

2012-02-06T19:44:47 endtime: 2012-02-07T05:44:47 renew till: 20
Quoted 5 lines
Quoted 5 lines

we can logon and request files via the mount.

Questions
Does this procedure prove that nfs can use other than DES crypto? Is arcfour what an AD admin would consider strong encryption?

As Andy said, modern Linux NFS supports all those "Cllient supported enctypes".

Re: strong encryption for AD. What version of Windows AD? If it is Windows 2003, then yes, I think arcfour would be considered strong. If it is Windows 2008 or later, AES is supported and is stronger. (Windows has never supported DES3).

K.C.

A message that is not in the archive (sent off-list or not yet received): CAGue13obwkrr4eWAdF0nyQZBhZrh4eSKeAgABV-cGd9cu-0zYA@mail.gmail.com

author
#4 lore raw
Quoted 17 lines · Tigran Mkrtchyan

Hi Steve,

Quoted 14 lines · steve

Hi
openSUSE 12.1

On hh6, root issues:
mount -t nfs4 hh3:/foo /bar -o sec=krb5 rpc.gssd -fvvv throws a fit, the KDC responds with,

Kerberos: ENC-TS Pre-authentication succeeded -- [email protected] using arcfour-hmac-md5
Kerberos: TGS-REQ [email protected] from ipv4:192.168.1.10:45421 for nfs/[email protected] [canonicalize, renewable]
Kerberos: TGS-REQ authtime: 2012-02-06T19:44:47 starttime:

2012-02-06T19:44:47 endtime: 2012-02-07T05:44:47 renew till: 20
Quoted 8 lines
Quoted 4 lines

we can logon and request files via the mount.

Questions
Does this procedure prove that nfs can use other than DES crypto?

you can check that with wireshark. My screen shot is attached.

Tigran.

Hi Tigran

Thanks for the reply. I only seem to get smb packets:
http://2.bp.blogspot.com/-5lxu8-GB44o/T05PfIR-vYI/AAAAAAAAARQ/pfYKQJh1AKM/s1600/w713.png

192.168.1.3 is a nfs, dns and samba server. 192.168.1.12 is a win 7 client. The nfs client at 192.168.1.8 doesn't figure, even though it's getting files and dns fine from the same server. What am I missing?

Sorry to trouble you.
Steve

#5 lore raw

Hi Steve,

you could try to enable capture filter like 'port 2049 and host 192.168.1.8'

to see only nfs traffic.

Tigran.

Quoted 41 lines · steve
Quoted 19 lines · Tigran Mkrtchyan

Hi Steve,

Quoted 15 lines · steve

Hi
openSUSE 12.1

On hh6, root issues:
mount -t nfs4 hh3:/foo /bar -o sec=krb5 rpc.gssd -fvvv throws a fit, the KDC responds with,

Kerberos: ENC-TS Pre-authentication succeeded -- [email protected] using arcfour-hmac-md5
Kerberos: TGS-REQ [email protected] from ipv4:192.168.1.10:45421 for nfs/[email protected] [canonicalize, renewable]
Kerberos: TGS-REQ authtime: 2012-02-06T19:44:47 starttime:

2012-02-06T19:44:47 endtime: 2012-02-07T05:44:47 renew till: 20
Quoted 9 lines
Quoted 4 lines

we can logon and request files via the mount.

Questions
Does this procedure prove that nfs can use other than DES crypto?

you can check that with wireshark. My screen shot is attached.

Tigran.

Hi Tigran

Thanks for the reply. I only seem to get smb packets:
http://2.bp.blogspot.com/-5lxu8-GB44o/T05PfIR-vYI/AAAAAAAAARQ/pfYKQJh1AKM/s1600/w713.png

192.168.1.3 is a nfs, dns and samba server. 192.168.1.12 is a win 7 client. The nfs client at 192.168.1.8 doesn't figure, even though it's getting files and dns fine from the same server. What am I missing?

Sorry to trouble you.
Steve