Re: [nfsv4] [secdir] SECDIR Review of draft-ietf-nfsv4-umask-03

[Watson Ladd <[e-mail]>]

On Wed, May 31, 2017 at 6:23 AM, David Noveck <[e-mail]> wrote:
> Phillip Hallam-Baker wrote
>> They are not so much a security plan as a collection of random thoughts
>> jotted down
>> in haphazard fashion.
>
> This is fair criticism.  I've looked through the Security Considerations
> sections of RFCs 3530, 7530, and 5661 and the differences are minor.   None
> of these sections were written to provide a security plan, but tried to
> describe, somewhat inelegantly, the evolution of NFS from its origins in a
> LAN environment towards NFSv4 which attempted to provide some reasonable
> security features.  Any security needs were provided by RPCSECGSS, and not
> by the protocol itself.
>
>> There is clearly no coherent model of what NFS security should achieve,
>> what the
>> threats are, what controls are deployed to control them
>
> An alternative would have been to define an entirely new protocol with a
> real security plan covering these matters, but that wasn't the goal then.
> If it had been, we would probably have a much more secure protocol that
> nobody would deploy.  What happened was that NFSv4 was defined requiring
> implementation, but not use, of RPCSECGSS.  Even today, many NFSv4
> deployments use AUTH_SYS and very few which use RPCSECGSS, use integrity or
> privacy, because of performance issues.  Security is provided by use of
> physically isolated networks or VPNs.   That was considered adequate when
> RFCs 3530, 5661, and 7530 were written and approved.

How does this address the sorts of problems associated with the NFS
permissions model? Furthermore, this candy bar network (crunchy shell
with gooey inside) is a real liability. It would be nice if we could
make it easier to move away from.

>
> If it is appropriate to move the goal posts here, based on current needs, we
> have to understand exactly what is being asked for, in order to see if
> remediation is possible while maintaining continuity with the existing NFSv4
> protocol and implementations.  Some possibilities:
>
> A clear security plan which defines the threats that NFSv4 addresses and is
> clear about those it does not address (and so have to addressed by other
> means).
> A security plan plan defining the threats that NFSv4 should address, how
> some of those are addressed by various NFSv4 minor versions, and others will
> be by extensions to NFSv4.2 or later minor versions.

I prefer the second, but it might never happen. The first is at least
useful (when combined with what NFSv4 could address as shown by other
systems of similar kind)

>
> Spencer Dawkins wrote:
>> Speaking as the responsible AD, I'm thinking that the right thing to do,
>> is for me to ask the NFSv4
>> working group to consider the issue you're raising, with the high-order
>> bit question being whether
>> it's time to revisit NFS security.
>
> If so, we need to better understand exactly what we need to do in this area
> and are able to do while supporting adequately other uses of NFS, in more
> controlled environments, where the concerns are different.
>
>> The working group is actively discussing a recharter, likely to be
>> discussed in Prague, so it's
>> the right time to ask the question.
>
> Yes.  Right now, one of the bulleted items in the extensions section of my
> proposed draft reads:
>
> Provide effective NFS response to increasing security challenges.
>
> It seems to me that the IESG might reasonably be skeptical of our attempt to
> address new/increasing security challenges, given the level of
> dissatisfaction with the base we are building on.
>
> My next draft will try to address the clarity needs regarding security in
> the Maintenance section.  In any case, the working group will have to
> discuss these issues in Prague.  As it is, we have allocated a total of 30
> minutes to the entire charter discussion, so there will probably only be
> time to begin the discussion and not reach a conclusion.
>
>> Given that RFC 7530 is the umbrella RFC for all of NFSv4.
>
> Actually, there is no umbrella RFC for all of NFSv4, which is a definite
> problem given reasonable precipitation expectations :-(
>
> RFC5661 is pretty clear about the the fact that it stands on its own.
>
> The only NFSv4 RFC that will apply to all of NFSv4 is the one that will
> arise from the vesioning work.  We could create others.
>
>> I'm thinking that's  the right place to fix anything that needs fixing.
>
> I think that will depend on what we decide is fixable, but any substantive
> securIty extensions would require definition in a new document.
>
> With regard to updating the Security Considerations section, we need to
> address both NFSv4.0 and NFSv4.1, so I don't see an rfc7530bis in our
> future.  If we are able to provide an appropriate updated treatment, it
> would have to be marked as updating RFCs 5661 and 7530.
>
>
>
> On Fri, May 26, 2017 at 12:00 PM, Spencer Dawkins at IETF
> <[e-mail]> wrote:
>>
>> Hi, Phillip,
>>
>> (adding the NFSv4 working group mailing list, because the issue you raised
>> in this review is relevant to pretty much all of NFSv4)
>>
>> On Thu, May 18, 2017 at 12:10 PM, Phillip Hallam-Baker
>> <[e-mail]> wrote:
>>>
>>> Reviewer:
>>> Phillip Hallam-Baker
>>>
>>> Review result:
>>> OK but...
>>>
>>>
>>> I reviewed this document as part of the Security Directorate's
>>> ongoing
>>> effort to review all IETF documents being processed by the IESG.
>>> These
>>> comments were written primarily for the benefit of the Security Area
>>> Directors.  Document authors, document editors, and WG chairs should
>>> treat these comments just like any other IETF Last Call comments.
>>>
>>> Document: Review of draft-ietf-nfsv4-umask-03
>>> Reviewer:
>>> Phillip Hallam-Baker
>>>
>>>
>>>
>>> Review result:
>>> OK but...
>>>
>>>
>>> This particular draft looks OK to me. Aligning the semantics of NFS with
>>> the semantics of the file system seems to me to be absolutely the way to go
>>> forward. I am not sufficiently experienced in the semantics of NFS or Unix
>>> as deployed to be able to offer an opinion on whether the draft achieves
>>> that. However it appears that the author does.
>>>
>>> What is problematic here is that the Security Considerations in the draft
>>> are essentially relying on those in rfc7530 which are woefully inadequate
>>> given the critical role of NFS in Internet security. They are not so much a
>>> security plan as a collection of random thoughts jotted down in haphazard
>>> fashion.
>>>
>>> There is clearly no coherent model of what NFS security should achieve,
>>> what the threats are, what controls are deployed to control them. Also note
>>> that the main reason this review is late is that I have been dealing with
>>> issues arising from WannaCry which used an SMB:1 exploit. Re-reading RFC7530
>>> in the light of that experience gives me grave concern.
>>
>>
>> This is very interesting ...
>>
>> Speaking as the responsible AD, I'm thinking that the right thing to do,
>> is for me to ask the NFSv4 working group to consider the issue you're
>> raising, with the high-order bit question being whether it's time to revisit
>> NFS security. The working group is actively discussing a recharter, likely
>> to be discussed in Prague, so it's the right time to ask the question.
>>
>> Given that RFC 7530 is the umbrella RFC for all of NFSv4, I'm thinking
>> that's the right place to fix anything that needs fixing.
>>
>> And thanks for your review.
>>
>> Spencer
>>
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>
>
> _______________________________________________
> secdir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.