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

From: spencer shepler <[email-masked]>
Date: Wed, 3 Apr 2013 13:45:55 -0700

Anyone like to address Ben's concern and propose a solution?

Spencer
---------- Forwarded message ----------
From: Benjamin Kaduk <[email-masked]>
Date: Mon, Apr 1, 2013 at 10:01 AM
Subject: Re: [nfsv4] Last Call: <draft-ietf-nfsv4-rfc3530bis-25.txt>
(Network File System (NFS) Version 4 Protocol) to Proposed Standard
To: [email-masked]
Cc: [email-masked]

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

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 3 Apr 2013 22:52:37 +0000

Yes, I'll address it on that list.

On Apr 3, 2013, at 1:45 PM, spencer shepler <[email-masked]<mailto:[email-masked]>> wrote:

Spencer
---------- Forwarded message ----------
From: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
Date: Mon, Apr 1, 2013 at 10:01 AM
Subject: Re: [nfsv4] Last Call: <draft-ietf-nfsv4-rfc3530bis-25.txt> (Network File System (NFS) Version 4 Protocol) to Proposed Standard
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

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

_______________________________________________
nfsv4 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 4 Apr 2013 04:14:54 +0000

> 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 t…

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

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 3 Apr 2013 21:38:21 -0700

Use the Security Considerations section of RFC5661 as a basis for
rfc3530-bis.

On Wed, April 3, 2013 1:45 pm, spencer shepler wrote:
> [email-masked]

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 3 Apr 2013 21:38:48 -0700

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 3 Apr 2013 21:38:55 -0700

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 3 Apr 2013 21:38:58 -0700

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 3 Apr 2013 21:39:00 -0700

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 3 Apr 2013 21:39:03 -0700

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 3 Apr 2013 21:39:10 -0700

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 3 Apr 2013 21:39:11 -0700

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 4 Apr 2013 13:36:08 -0400 (EDT)

Hi Tom, Nico,

> On Apr 1, 2013, at 10:01 AM, Benjamin Kaduk <[email-masked]> wrote:
[snip.  Single-DES is weak and deprecated]
> was done before RFC 6649 was published.

It did look like the Kerberos portions of the document had not been 
touched since the previous revision; RFC 6649 was probably later in coming 
than it should have been.

> implementations based solely on RFC 3530.

Understood.  The DES-migration process has been and continues to be a long 
process; on the Kerberos side we're mostly done, but applications still 
need to adapt.  (I'm working on updates for AFS, which had DES baked into 
it pretty thoroughly.)  Thus, part of the work of the Kerberos folks is to 
actively encourage people to migrate away from DES -- though there's not 
much we can do about old standards still being used, new standards should 
encourage migration.  In this vein, my preference would be for this 
document to actively mention migration away from DES, though I understand 
that this is a stronger sentiment than is strictly speaking necessary.

Part of my concern stems from the fact that there are existing NFSv4 
implementations which remain DES-only, and I would like this document to 
strongly encourage those implementations to add support for strong crypto.

> Does this alleviate your concern?

The quoted text would be a big improvement, but does not seem like a 
complete solution -- the table would need to be updated to remove the 
algorithm column, probably as per Nico's suggestion.  It also seems like 
section 2.2.1.1.1.2.1.1 of RFC 5661 is still applicable:

    When deploying NFSv4.1, the strength of the security achieved depends
    on the existing Kerberos V5 infrastructure.  The algorithms of
    Kerberos V5 are not directly exposed to or selectable by the client
    or server, so there is some due diligence required by the user of
    NFSv4.1 to ensure that security is acceptable where needed.

This would be a good place to reference RFC 6649 and/or mention that 
modern Kerberos implementations disable weak algorithms by default, as 
part of the "active encouragement" that I would prefer.

On Wed, 3 Apr 2013, Nico Williams wrote:

> Oh, well, this is just outdated text.  And indeed, the GSS-API's
> notion of "qop" (quality of protection) is broken: it's used in the
> wrong place (per-msg token functions).  The GSS qop brokenness is why
> this text persists.
>
[snip]
>
> NEW:
>   1 == number of pseudo flavor
>   2 == name of pseudo flavor
>   3 == mechanism's OID
>   4 == qop
>   5 == RPCSEC_GSS service
>
>   1      2     3                    4             5
>   --------------------------------------------------------------------
>   390003 krb5  1.2.840.113554.1.2.2 0   rpc_gss_svc_none
>   390004 krb5i 1.2.840.113554.1.2.2 0   rpc_gss_svc_integrity
>   390005 krb5p 1.2.840.113554.1.2.2 0   rpc_gss_svc_privacy
>
> Actually, I should also propose some text explaining why qop is a
> busted concept and what qop 0 means ("default").

The table in RFC 5661 also includes columns for whether the flavor is 
mandatory for clients and servers, but it looks like they are now always 
mandatory and those columns are not needed.

In combination with Tom's proposed changes, this table should work well.
Agreed that some text about what qop 0 means is needed.

> KITTEN WG should undertake an extension to replace the broken qop concept.

I worry that such an undertaking would degenerate into a full GSS-API 
rewrite, but regardless that's out of scope for the current discussion.

Thanks for the updates,

Ben

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 Apr 2013 13:50:51 -0500

> In combination with Tom's proposed changes, this table should work well.

I agree.

> Agreed that some text about what qop 0 means is needed.

I yes.  Indeed, maybe we should even remove the qop column and state
that we always use qop 0 unless otherwise stated (and we'll not state
otherwise).

> rewrite, but regardless that's out of scope for the current discussion.

I don't think so.  We've discussed it [since] on IRC, and it's not
relevant here so I'll not burden the cc'ed with it.  I'll bring
something to KITTEN WG about this *after* the interim meeting that's
coming up, but NFSv4 WG should not wait for it.

Nico
--

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 30 Apr 2013 16:50:17 +0200

Not sure the WG has seen this message.

-------- Original Message --------
Subject: Re: [nfsv4] Last Call: <draft-ietf-nfsv4-rfc3530bis-25.txt> 
(Network File System	(NFS) Version 4 Protocol) to Proposed Standard
Date: Mon, 1 Apr 2013 13:01:06 -0400
From: Benjamin Kaduk <[email-masked]>
To: <[email-masked]>
CC: <[email-masked]>

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

-- 
[email-masked]

NEC Laboratories Europe
NEC Europe Limited
Registered Office:
Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB
Registered in England 2832014