Re: [secdir] [nfsv4] Last Call: <draft-ietf-nfsv4-rfc3530bis-25.txt> (Network File System (NFS) Version 4 Protocol) to Proposed Standard

"Haynes, Tom" <Tom.Haynes@netapp.com> Thu, 04 April 2013 04:14 UTC

Return-Path: <Tom.Haynes@netapp.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D1711E80A5; Wed, 3 Apr 2013 21:14:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAkkJbe6Is58; Wed, 3 Apr 2013 21:14:55 -0700 (PDT)
Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id BAA6021F8A4F; Wed, 3 Apr 2013 21:14:55 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,405,1363158000"; d="scan'208";a="36922071"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 03 Apr 2013 21:14:55 -0700
Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r344EtB7008861; Wed, 3 Apr 2013 21:14:55 -0700 (PDT)
Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.175]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0342.003; Wed, 3 Apr 2013 21:14:54 -0700
From: "Haynes, Tom" <Tom.Haynes@netapp.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Thread-Topic: [nfsv4] Last Call: <draft-ietf-nfsv4-rfc3530bis-25.txt> (Network File System (NFS) Version 4 Protocol) to Proposed Standard
Thread-Index: AQHOJK1Hk1lo2vsfCEaGISRIWfn6TZjCIP0AgAPg6QA=
Date: Thu, 04 Apr 2013 04:14:54 +0000
Message-ID: <830AD203-2C2A-428F-A952-08B8F5A727E9@netapp.com>
References: <20130319142244.19905.39903.idtracker@ietfa.amsl.com> <alpine.GSO.1.10.1303312327530.9389@multics.mit.edu>
In-Reply-To: <alpine.GSO.1.10.1303312327530.9389@multics.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.104.60.118]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4F13949B2D100146887AC8DB4086D04F@tahoe.netapp.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 04 Apr 2013 02:21:03 -0700
Cc: "ietf@ietf.org" <ietf@ietf.org>, nfsv4 list <nfsv4@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] [nfsv4] Last Call: <draft-ietf-nfsv4-rfc3530bis-25.txt> (Network File System (NFS) Version 4 Protocol) to Proposed Standard
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2013 04:14:57 -0000

On Apr 1, 2013, at 10:01 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:

> I have not yet completed a full review of this (320-page) document, and I worry that I may not finish before the deadline, so I am bringing this concern to your attention now.
> 
> Section 3.2.1.1 of this document ("Kerberos V5 as a security triple") seems to indicate that it is mandatory for a conformant NFSv4 implementation to implement the Kerberos V5 GSS-API mechanism and a few "security triples" (mechanism,quality of protection,service).  All of the mandatory-to-implement security triples use the DES-MAC-MD5 algorithm. The draft goes on to indicate that clients should engage in security negotiation (section 3.3) to determine what security to use for bulk operation, and that since kerberos-v5 under RPCSEC_GSS is mandatory, the negotiation will be performed using that security provider.  The actual mechanism resulting from the negotiation may be different (or may be the same), but this single-DES mechanism seems to be required to be used to protect the negotiation step.
> 
> Given that the kerberos working group has published RFC 6649 (Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos) and single-DES is known to be critically vulnerable to brute-force attacks, I have grave concern about the IETF publishing new standards documents that mandate the implementation of single-DES and do not specify strong cryptographic algorithms.  I feel that to do so would be misleading implementors into believing that single-DES is sufficient and other mechanisms need not be implemented, when in reality this is not true.
> 
> Sincerely,
> 
> Ben Kaduk
> MIT Kerberos Consortium


Hi Ben,

Thanks for pointing this out - the last work on Kerberos for this bis
was done before RFC 6649 was published.

While I can propose that we modify the text to point to take RFC 6649
into consideration and to deprecate DES for Kerberos in NFSv4
implementations, this will in no way invalidate the use of DES in shipping
implementations based solely on RFC 3530.

We did have the following in RFC 3530:

   Users and implementors are warned that 56 bit DES is no longer
   considered state of the art in terms of resistance to brute force
   attacks.  Once a revision to [RFC1964] is available that adds support
   for AES, implementors are urged to incorporate AES into their NFSv4
   over Kerberos V5 protocol stacks, and users are similarly urged to
   migrate to the use of AES.

And in RFC 5661, we have this wording:

   At the time NFSv4.1 was specified, the Advanced Encryption Standard
   (AES) with HMAC-SHA1 was a REQUIRED algorithm set for Kerberos V5.
   In contrast, when NFSv4.0 was specified, weaker algorithm sets were
   REQUIRED for Kerberos V5, and were REQUIRED in the NFSv4.0
   specification, because the Kerberos V5 specification at the time did
   not specify stronger algorithms.  The NFSv4.1 specification does not
   specify REQUIRED algorithms for Kerberos V5, and instead, the
   implementor is expected to track the evolution of the Kerberos V5
   standard if and when stronger algorithms are specified.

And instead of referencing RFC 1964, it instead references:

   [5]   Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version
         5 Generic Security Service Application Program Interface (GSS-
         API) Mechanism Version 2", RFC 4121, July 2005.

My proposal is that we adopt the language from RFC 5661:

   At the time of this document, the Advanced Encryption Standard
   (AES) with HMAC-SHA1 was a REQUIRED algorithm set for Kerberos V5.
   In contrast, when NFSv4.0 was first specified, weaker algorithm sets were
   REQUIRED for Kerberos V5, and were REQUIRED in the NFSv4.0
   specification, because the Kerberos V5 specification at the time did
   not specify stronger algorithms.  The NFSv4.0 specification no longer
   specifies REQUIRED algorithms for Kerberos V5, and instead, the
   implementor is expected to track the evolution of the Kerberos V5
   standard if and when stronger algorithms are specified.

In essence, the proposal is to replace Section 3.2 in 3530bis with
that of Section 2.2.1 of 5661. You would not see DES in the new
content.

Does this alleviate your concern?

Thanks,
Tom