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

[David Noveck <[e-mail]>]

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.

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.

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
>
>