Hi Tom, Nico,
On Thu, 4 Apr 2013, Haynes, Tom wrote:
On Apr 1, 2013, at 10:01 AM, Benjamin Kaduk <kaduk@xxxxxxx> 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