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

[Benjamin Kaduk <[e-mail]>]

Hi Tom, Nico,

On Thu, 4 Apr 2013, Haynes, Tom wrote:

>
> On Apr 1, 2013, at 10:01 AM, Benjamin Kaduk <[e-mail]> wrote:
>
[snip.  Single-DES is weak and deprecated]
>
>
> Hi Ben,
>
> Thanks for pointing this out - the last work on Kerberos for this bis
> 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.

> 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.

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.

> 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?

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