Subject: [nfsv4] [Fwd: Re: DISCUSS: draft-ietf-nfsv4-minorversion1]

From: "Mike Eisler" <[email-masked]>
Date: Thu, 4 Dec 2008 07:48:05 -0800 (PST)

This means barring objection from the WG,
that SPKM and LIPKEY will be dropped from NFSv4.1, in -28
of the I-D. Today.

Object if you want, but before you do, decide if want a pNFS spec
sometime in 2009 or 2010.

---------------------------- Original Message ----------------------------
Subject: [Fwd: Re: DISCUSS: draft-ietf-nfsv4-minorversion1]
From:    [email-masked]
Date:    Thu, December 4, 2008 7:24 am
To:      [email-masked]
         [email-masked]
--------------------------------------------------------------------------

---------------------------- Original Message ----------------------------
Subject: Re: DISCUSS: draft-ietf-nfsv4-minorversion1
From:    [email-masked]
Date:    Thu, December 4, 2008 6:49 am
To:      "Tim Polk" <[email-masked]>
Cc:      [email-masked]
         [email-masked]
         [email-masked]
--------------------------------------------------------------------------

I will turn around an updated I-D as soon as possible.

> Discuss:
> [This is an updated discuss.  Issue #2 is new]
>
> Issue #1
>
> This specification includes three mandatory to implement security
> mechanisms:
> Kerberos; LIPKEY; and SPKM-3.
>
> The LIPKEY and SPKM-3 mechanisms (specified in RFC 2847) are only defined
> with respect to a small number of  cryptographic algorithms, and most of
> them
> are weak. 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.  Neither encryption algorithm
> would
> be considered an acceptable choice today.  While some of the integrity
> algorithms
> are still marginally acceptable, even the strongest (SHA1-RSA and
> DSA-SHA1) are
> at the end of their useful lifespan.    There are also no restrictions or
> guidance with
> respect to key sizes for DSA or RSA in RFC 2847.
>
> To make matters worse, implementers in the security directorate find that
> LIPKEY
> and SPKM-3 are underspecified, so interoperability of these options can be
> problematic.
>
> These problems are exacerbated by a lack of guidance in the body or
> security considerations
> section.  There is nothing to indicate that the security provided by these
> three mandatory
> to implement mechanisms is inconsistent.
>
> I believe that LIPKEY and SPKM-3 should be removed from the mandatory to
> implement
> security mechanism list.  If the wg feels strongly they should be
> retained, they should
> become optional, and thorough applicability text describing when these
> mechanisms are
> appropriate and detailing the limited security achieved must be added.
>
> It would also be helpful if the text on Kerberos was expanded to note that
> the mandatory
> to implement algorithm set is now AES with HMAC-SHA1, based on the
> reference to RFC 4121.
> This is a very significant improvement, since v4 referenced earlier
> Kerberos specifications
> relying on DES and MD5, but is not highlighted anywhere in the
> specification.
>
> Finally, a brief note in the secuirty considerations text on cryptographic
> algorithms might
> be helpful.  When deploying NFSv4.1, the security achieved is largely
> dependent on the
> existing Kerberos infrastructure.  The algorithms are not directly exposed
> to or selectable
> by the client or server, so there is some due diligence required to ensure
> that security
> is acceptable where needed.
>
> Issue #2
>
> The security implications of pNFS are significant.  They are clearly
> documented in section
> 12.9, but I believe they merit an earlier mention.  Specifically, sections
> 1.6.1 and 1.6.2.2
> should be updated to note that the traditional security framework is
> modified by the
> introduction of pNFS.
>
>
>

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

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 4 Dec 2008 13:27:47 -0500

No objection but my understanding is that they are not being removed in
that you can still implement them if you want.  It is only that they are
not mandatory to implement. 

They are still mandatory-to-implement in v4.0 even though nobody (?) has
done so.  So this way, in v4.1, we don't have to feel so guilty.

BTW, wasn't this another case where we have something that we were
pushed to do something for v4.0 which is now objectionable when it is
carried forward to v4.1 (stringprep is definitely one)?

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Thursday, December 04, 2008 10:48 AM
To: [email-masked]
Subject: [nfsv4] [Fwd: Re: DISCUSS: draft-ietf-nfsv4-minorversion1]

---------------------------- Original Message
----------------------------
Subject: [Fwd: Re: DISCUSS: draft-ietf-nfsv4-minorversion1]
From:    [email-masked]
Date:    Thu, December 4, 2008 7:24 am
To:      [email-masked]
         [email-masked]
------------------------------------------------------------------------
--

---------------------------- Original Message
----------------------------
Subject: Re: DISCUSS: draft-ietf-nfsv4-minorversion1
From:    [email-masked]
Date:    Thu, December 4, 2008 6:49 am
To:      "Tim Polk" <[email-masked]>
Cc:      [email-masked]
         [email-masked]
         [email-masked]
------------------------------------------------------------------------
--

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 4 Dec 2008 10:46:50 -0800 (PST)

> not mandatory to implement.

One can implement and use any GSS-API mechanism one wants to.
Just plug it into GSS.

> carried forward to v4.1 (stringprep is definitely one)?

Yes, LIPKEY was a result of a previous AD's requirement.

IETF has very dynamic requirements.