Subject: Re: [secdir] Question about NFSv4/NFSv4.1 crypto support

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 03 Dec 2008 12:18:51 -0500

--On Wednesday, December 03, 2008 09:57:59 AM -0500 Tim Polk 
<[email-masked]> wrote:

> The mandatory security mechanisms are Kerberos, LIPKEY and SPKM-3.
> REPCSEC_GSS can be used to negotiate other mechanisms, but my
> immediate concern is the mandatory to implements.

> Kerberos is certainly well-specified for an acceptable range of
> algorithms,
> but as I understand RFC 3530, the krb5, krb5i and krb5p pseudo flavors
> rely on DES and MD5 for security services.  (Perhaps I am misreading
> this, and the implication is that DES and MD5 are the mandatory to
> implement algorithms, but that still would be unacceptable in my mind.)

In this case, it matters which references you follow.
RFC3530 (nfsv4) refers to RFC1964 (krb5-GSS), which refers to RFC1510 
(krb5).  In that version of krb5, the mandatory-to-implement enctype was 
DES-CBC-MD5.

In nfsv4-minorversion1, the krb5-gss reference is to RFC4121, which refers 
in turn to RFC4120 (krb5), in which the mandatory-to-implement enctype is 
AES256-CTS-HMAC-SHA1-96, which should be plenty strong enough.

> The LIPKEY and SPKM-3 mechanisms are only defined with respect to a
> small number of algorithms, and most of them are weak.  The  mandatory
> to implement for LIPKEY seems to be MD5 and Cast5 (a.k.a., CAST-128)
> if  I understand RFC 3530 correctly.  SPKM-3 (and by extension, LIPKEY)
> is specified for DES and  CAST5 as encryption algorithms and MD5-RSA,
> DES-MAC, DSA-SHA1, HMAC-MD5, and SHA1-RSA are the only integrity
> algorithms.  There are also no restrictions or guidance with respect to
> key
> sizes for DSA or RSA.

I don't know the current thinking on this among people working on NFSv4, 
but I believe that draft-zhu-pku2u-09.txt intends to be a successor to 
SPKM-3 in this space.  Unfortunately, while I think it's nearly ready for 
last call (and I should have a writeup to you shortly, if I still think so 
after a final review), it's lagging a bit behind NFSv4.1 in that respect.

-- Jeff
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Dec 2008 11:49:13 -0600

On Wed, Dec 03, 2008 at 12:18:51PM -0500, Jeffrey Hutzelman wrote:
> >small number of algorithms, and most of them are weak.  The
> >mandatory to implement for LIPKEY seems to be MD5 and Cast5 (a.k.a.,
> >CAST-128) if  I understand RFC 3530 correctly.  SPKM-3 (and by
> >extension, LIPKEY) is specified for DES and  CAST5 as encryption
> >algorithms and MD5-RSA, DES-MAC, DSA-SHA1, HMAC-MD5, and SHA1-RSA are
> >the only integrity algorithms.  There are also no restrictions or
> >guidance with respect to key sizes for DSA or RSA.

Worse, LIPKEY and SPKM-3 implementations are hard to find, impossible to

> after a final review), it's lagging a bit behind NFSv4.1 in that respect.

PKU2U will replace SPKM-3.  PKU2U makes LIPKEY-based-on-PKU2U much more
likely to be deployed.  Which means that the dependency of LIPKEY,
though very shaky *now*, is likely to be a good one down the line.

Today the only GSS-API mechanism in use in real-world NFSv4 deployments
of NFSv4 is Kerberos V, in its RFC4121 form (meaning with support for
AES).

Nico
--

---

From: Tim Polk <[email-masked]>
Date: Wed, 3 Dec 2008 13:23:40 -0500

Jeff,

Thanks for the clarifications!

Since 3530 explicitly called out DES and MD5, and nfsv4-minorversion1  
did not
explicitly call out anything, I failed to note the all-important  
reference update!
That is *exactly* what I was looking for - at least one mandatory to  
implement
mechanism that had reasonable cryptographic security.

The weakness of SPKM-3 and LIPKEY is less of a concern as a result, but
probably needs to be sorted in the future.   At least we don't need  
to block this
document see the referenced Kerberos suite is acceptable.

I suspect the security considerations will need to be expanded to  
address this
topic, though.

Thanks,

Tim

On Dec 3, 2008, at 12:18 PM, Jeffrey Hutzelman wrote:

> RFC3530 (nfsv4) refers to RFC1964 (krb5-GSS), which refers to  
> RFC1510 (krb5).  In that version of krb5, the mandatory-to- 
> implement enctype was DES-CBC-MD5.
>
> In nfsv4-minorversion1, the krb5-gss reference is to RFC4121, which  
> refers in turn to RFC4120 (krb5), in which the mandatory-to- 
> implement enctype is AES256-CTS-HMAC-SHA1-96, which should be  
> plenty strong enough.
>
>> mandatory
> I don't know the current thinking on this among people working on  
> NFSv4, but I believe that draft-zhu-pku2u-09.txt intends to be a  
> successor to SPKM-3 in this space.  Unfortunately, while I think  
> it's nearly ready for last call (and I should have a writeup to you  
> shortly, if I still think so after a final review), it's lagging a  
> bit behind NFSv4.1 in that respect.
>
> -- Jeff

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Dec 2008 10:31:46 -0800

At 1:23 PM -0500 12/3/08, Tim Polk wrote:
>Since 3530 explicitly called out DES and MD5, and nfsv4-minorversion1 did not
>explicitly call out anything, I failed to note the all-important reference update!

...which means that implementers might miss it as well. Maybe an explicit mention of the dereferenced mandatory-to-implement crypto in the base spec would be a good thing.

>probably needs to be sorted in the future.

Why not now? You just had two implementers say that it was bad; why even let implementers have to consider it?
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Tim Polk <[email-masked]>
Date: Wed, 3 Dec 2008 13:57:30 -0500

Hi Paul,

On Dec 3, 2008, at 1:31 PM, Paul Hoffman wrote:

> ...which means that implementers might miss it as well. Maybe an  
> explicit mention of the dereferenced mandatory-to-implement crypto  
> in the base spec would be a good thing.

Yes, I will suggest it, but I probably don't need to consider it  
blocking...

> Why not now? You just had two implementers say that it was bad; why  
> even let implementers have to consider it?

What I meant was having a strong mandatory to implement mechanism  
(the 4121 solution) makes this pair of weak
mandatory to implement mechanisms less of a concern.  If the  
implementations don't actually support these mechanisms,
and they are under specified to boot, then that is a different sort  
of problem.  It sounds like LIPKEY and SPKM-3 should
either be specified as optional or removed entirely.

Thanks,

Tim

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 03 Dec 2008 14:39:12 -0500

> Yes, I will suggest it, but I probably don't need to consider it

I agree.  The truth is that implementors don't actually have to do anything 
here; they don't even really have much control over what enctype gets used. 
Unless your implementation is an embedded box where you get to choose what 
Kerberos libraries you get, which admittedly will be a common case for 
NFSv4 implementations.
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir