On Apr 1, 2013, at 10:01 AM, Benjamin Kaduk <kaduk(_at_)mit(_dot_)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